Как работают ключи шифрования: основа безопасности файлов

Ключ шифрования — это строка случайных битов, которая блокирует и разблокирует данные. Для современной передачи файлов это, как правило, 256-битный ключ AES — 32 байта случайных данных, сгенерированных криптографически стойким генератором случайных чисел (CSPRNG). Тот же алгоритм, который превращает 10-гигабайтное видео в шифртекст, может расшифровать его только при наличии точно того же ключа. Безопасность шифрования определяется именно ключом: безупречный шифр AES-256 бесполезен, если ключ слабый, предсказуемый или скомпрометированный. В этой статье рассматривается, как ключи создаются, передаются, хранятся и уничтожаются в реальных сервисах — HexaTransfer, Tresorit и Proton Drive.

Ключи — это просто случайные числа

256-битный ключ — это 32 байта. При генерации в браузере он выглядит так:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

«Ключом» его делает то, как алгоритм его использует. AES-256-GCM берёт 256-битный ключ, разворачивает его через расписание ключей в 15 раундовых ключей и использует их для обработки 128-битных блоков через 14 раундов. Математике всё равно, откуда взялись биты — главное, чтобы они были секретными и непредсказуемыми.

«Непредсказуемость» — более сложное требование. Если злоумышленник сможет угадать состояние вашего генератора случайных чисел, он сможет воссоздать ваш ключ. Ошибка в Debian OpenSSL 2006 года снизила энтропию ключей до 15 бит на два года — классический пример того, что происходит при сбое генерации случайности.

Криптографически стойкая случайность

Браузеры предоставляют crypto.getRandomValues(), который обращается к CSPRNG операционной системы: /dev/urandom в Linux, BCryptGenRandom в Windows, SecRandomCopyBytes в macOS. Они в свою очередь смешивают несколько источников энтропии — тайминги прерываний, времена обращения к диску, аппаратные чипы RNG, такие как Intel RDRAND.

Не используйте Math.random() для ключей. Это предсказуемый генератор Mersenne Twister, состояние которого часто можно восстановить по нескольким выходным значениям.

На серверной стороне crypto.randomBytes() в Node.js и secrets.token_bytes() в Python оборачивают CSPRNG операционной системы и безопасны. Стандарты NIST SP 800-90A и SP 800-90B определяют требования к CSPRNG; ядро Linux 5.17+ использует конструкцию на основе BLAKE2s, соответствующую этим требованиям.

Симметричные ключи: один ключ, два направления

Симметричные алгоритмы, такие как AES, используют один ключ как для шифрования, так и для расшифрования. Варианты размеров ключей:

128 бит — 2^128 возможных значений, безопасен для большинства задач, одобрен для уровня SECRET согласно NSA CNSSP-15.
192 бита — редко используется, применяется в ряде государственных контекстов.
256 бит — 2^256 значений, одобрен для уровня TOP SECRET, текущий стандарт для сервисов передачи файлов.

Удвоение размера ключа не удваивает сложность перебора — оно возводит её в квадрат. 2^128 уже недостижимо (возраст вселенной, умноженный на 10 миллиардов, со всеми компьютерами Земли). 256-битный ключ — это страховка от квантовых компьютеров, где алгоритм Гровера эффективно вдвое снижает стойкость симметричных ключей.

Главная проблема симметричных ключей: как безопасно передать один и тот же ключ обеим сторонам, не допустив перехвата.

Асимметричные ключи: принцип пары

Криптография с открытым ключом решает проблему распределения ключей. Каждая сторона генерирует математически связанную пару ключей: открытый ключ (публично распространяется) и закрытый ключ (хранится в тайне). Всё зашифрованное открытым ключом может быть расшифровано только закрытым.

Распространённые типы асимметричных ключей:

RSA-2048 — модуль 2048 бит, широко поддерживается, медленный. Используется в TLS-сертификатах.
RSA-4096 — надёжнее, ещё медленнее.
Curve25519 (X25519) — 256-битный ключ на основе эллиптической кривой, быстрый, используется в Signal и WireGuard.
Ed25519 — 256-битный ключ подписи, используется в SSH и подписи коммитов Git.

Закрытый ключ занимает 32–512 байт в зависимости от алгоритма. Закрытые ключи RSA крупнее, так как содержат несколько простых чисел; закрытые ключи Curve25519 — это просто 32 случайных байта.

Гибридная схема: сочетание для реальных систем

Ни одна практическая система не шифрует большие файлы напрямую с помощью RSA. Вместо этого все реальные протоколы — TLS, PGP, Age, Signal, каждый серьёзный сервис передачи файлов — используют гибридное шифрование:

Генерируется случайный 256-битный ключ AES («сессионный ключ» или «ключ файла»).
Файл шифруется с помощью AES-256-GCM.
Сессионный ключ шифруется открытым ключом получателя.
Отправляются оба компонента.

Получатель расшифровывает сессионный ключ своим закрытым ключом, затем использует его для расшифровки файла. Вы получаете скорость симметричного шифрования и удобство асимметричного распределения ключей.

Для браузерной передачи файлов «открытый ключ» часто заменяется фрагментом URL: отправитель генерирует сессионный ключ, встраивает его в URL после #, и браузер получателя считывает его локально. Это проще и не требует наличия пары ключей у получателя.

Производство ключей из паролей

Пользователи вводят пароли; алгоритмы ожидают равномерно распределённые случайные биты. Функция деривации ключей (KDF) обеспечивает этот переход:

PBKDF2-HMAC-SHA-256 — итерирует хеш-функцию. OWASP 2023 рекомендует минимум 600 000 итераций. Доступна в Web Crypto API.
scrypt — устойчива к памяти, противостоит GPU-атакам. Параметры: N=2^17, r=8, p=1.
Argon2id — современная лучшая практика, победитель Password Hashing Competition 2015 года. Параметры: memory=64 МБ, iterations=3, parallelism=4.

KDF добавляет соль (случайные данные, хранящиеся вместе с шифртекстом) и рабочий фактор (количество итераций) для замедления перебора. 12-символьный случайный пароль через Argon2id с 64 МБ памяти потребует от GPU-фермы тысячи лет для полного перебора. Слабый пароль типа summer2024 падёт за секунды вне зависимости от KDF — функция деривации не может добавить энтропию, которой не было изначально.

Хранение ключей: где живут ключи

Ключи должны где-то храниться, и это место — критически важное решение с точки зрения безопасности:

Память браузера (только на время сессии). Стандарт для эфемерной передачи файлов. Ключ генерируется, используется и уничтожается в рамках загрузки страницы.
Фрагмент URL. Передаётся через ссылку, хранится в истории браузера получателя. Ограниченный срок жизни важен.
Local storage / IndexedDB. Постоянные, но доступны любому JavaScript на домене. Рискованно без дополнительного шифрования.
Связка ключей ОС — macOS Keychain, Windows DPAPI, Linux libsecret. На некоторых платформах имеет аппаратную поддержку.
Аппаратный модуль безопасности (HSM) — YubiKey, облачный HSM (AWS CloudHSM, Azure Dedicated HSM). Ключи никогда не покидают устройство.
Сервис управления ключами (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Централизованный, с аудитом, стоимостью около $1/ключ/месяц.

Для передачи файлов с нулевым знанием ключ хранится во фрагменте URL и браузере отправителя. Сервер его никогда не получает.

Ротация и уничтожение ключей

Долго живущие ключи накапливают риски. Лучшая практика — регулярная ротация:

TLS-сертификаты: ротация каждые 90 дней (стандарт Let's Encrypt), максимум 398 дней для публичных CA с 2020 года.
Ключи шифрования данных: как правило, ротируются каждые 90 дней — 1 год в соответствующих системах (PCI DSS 4.0, требование 3.6).
Мастер-ключи: ротируются ежегодно или при смене персонала.

Уничтожение тоже важно. Простое удаление файлов ключей с диска недостаточно — SSD может сохранять данные в зонах выравнивания износа. Безопасное уничтожение требует перезаписи или специальных команд удаления на HSM. Криптографическое стирание — уничтожение ключа, которое делает зашифрованные данные навсегда нечитаемыми, — часто является наиболее чистым подходом для больших объёмов данных.

Сервисы передачи файлов, как правило, используют ключи на уровне отдельных файлов, существующие только в течение срока жизни передачи (от 24 часов до 7 дней) и удаляемые вместе с шифртекстом по истечении срока.

Как распознать слабые практики работы с ключами

Три распространённые ошибки, на которые стоит обращать внимание:

Жёстко закодированные ключи в клиентском коде. Если ключ одинаков для всех пользователей, это не ключ — это маскировка.
Ключи хранятся рядом с шифртекстом на том же сервере или в той же базе данных. Взлом открывает доступ к обоим.
Отсутствие ротации ключей. Устаревшие системы с десятилетними ключами шифрования несут примерно десятилетний накопленный риск компрометации.

Авторитетный сервис публикует криптографический технический документ, охватывающий генерацию, хранение, ротацию и уничтожение ключей, и проходит независимые аудиты от таких компаний, как Cure53 или Trail of Bits.

Практические рекомендации

Для конфиденциального обмена файлами: выбирайте сервис, который генерирует 256-битные ключи на стороне клиента через crypto.getRandomValues(), встраивает их только во фрагмент URL (никогда не отправляя на сервер), поддерживает ключи, производные от пароля, через PBKDF2 или Argon2id, и автоматически удаляет и ключ, и шифртекст через 24 часа.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.