Методы шифрования передачи файлов: детальное сравнение

Сервисы передачи файлов используют в 2026 году пять основных подходов к шифрованию: только TLS (данные шифруются при передаче, но хранятся на сервере в открытом виде), серверное AES-256 at rest (провайдер хранит ключи), клиентское AES-256-GCM через Web Crypto API (сквозное шифрование, ключ во фрагменте URL), потоковое шифрование XChaCha20-Poly1305 (расширенный nonce, используется в libsodium и Tresorit), а также гибридное OpenPGP (ECC Curve25519 + сессионные ключи AES-256, используется в Proton). Выбор зависит от модели угроз, требований к производительности и регуляторных требований. Это сравнение объясняет, что делает каждый метод и в чём он уязвим.

Пять моделей шифрования

Модель первая: только TLS 1.3. Файл шифруется при сетевой передаче, а затем хранится на сервере в открытом виде. Примеры: базовый FTP поверх TLS (FTPS), любая загрузка по HTTP POST без шифрования at rest. Защищает от пассивного прослушивания сети — и больше ни от чего.

Модель вторая: TLS + серверное шифрование at rest. AES-256 шифрует хранящийся файл; провайдер хранит мастер-ключ (часто в AWS KMS, GCP Cloud KMS или аналоге). Примеры: WeTransfer, SwissTransfer, Dropbox. Защищает от кражи накопителя, но не защищает от инсайдерского доступа, судебного предписания или компрометации живого сервера.

Модель третья: клиентское E2EE с симметричным ключом. Браузер или клиент формирует 256-битный ключ, шифрует AES-256-GCM и помещает ключ во фрагмент URL или передаёт по отдельному каналу. Примеры: HexaTransfer, потомки протокола Firefox Send. Сервер видит только зашифрованный текст и не может расшифровать его ни при каких обстоятельствах.

Модель четвёртая: аутентифицированные потоковые шифры. XChaCha20-Poly1305 использует 24-байтные nonce (против 12-байтных в ChaCha20-Poly1305), что делает коллизии по критерию «дней рождения» невозможными даже для очень больших файлов. Примеры: libsodium secretbox (Internxt), Tresorit Send. Выбирается там, где аппаратное ускорение AES-NI недоступно (старые Android-устройства, IoT), так как ChaCha20 быстро работает программно.

Модель пятая: гибридное шифрование с открытым ключом. OpenPGP (RFC 9580, редакция 2024 года) использует ECC Curve25519 или RSA-4096 для шифрования сессионного ключа AES-256 на файл. Примеры: Proton Drive, традиционное шифрование GPG. Обеспечивает асимметричное управление ключами: общий секрет между отправителем и получателем не нужен при наличии открытого ключа получателя.

AES-256 против ChaCha20: реальные различия

Оба являются 256-битными симметричными шифрами. AES-256 — стандарт NIST (FIPS 197) с аппаратным ускорением (AES-NI на x86, ARM Cryptography Extensions на мобильных устройствах). На современном железе AES-256-GCM работает на скорости 2–4 ГБ/с на ядро. ChaCha20-Poly1305 в чистом программном режиме — 1–2 ГБ/с на ядро, но быстрее AES на железе без AES-NI. Для настольного ПК, шифрующего файл 4 ГБ, оба заканчивают работу менее чем за две секунды: узкое место — сеть, а не процессор. С криптографической точки зрения оба считаются одинаково стойкими в 2026 году.

RSA практически уходит из сферы передачи файлов

RSA-4096 шифрует 512 байт открытого текста за одну операцию. Применять RSA напрямую для шифрования файла в 1 ГБ бессмысленно: пришлось бы разбивать его на миллионы 512-байтных блоков. Схема всегда гибридная: RSA оборачивает сессионный ключ AES-256 на файл, AES шифрует содержимое. ECC Curve25519 вытеснил RSA в большинстве новых архитектур: быстрее, меньше размер ключей (256-битный ECC эквивалентен безопасности RSA-3072), устойчив к атакам по времени. OpenPGP в редакции 2024 года теперь рекомендует Curve25519 (X25519 для обмена ключами) вместо RSA. RSA по-прежнему встречается в устаревших SFTP-развёртываниях.

Почему ключи во фрагменте URL имеют значение

HexaTransfer и потомки протокола Firefox Send помещают ключ шифрования во фрагмент URL (часть после #). Браузеры по спецификации (RFC 3986) никогда не передают фрагменты в HTTP-запросе. Это означает, что сервер получает запрос вида GET /file/abc123, но никогда не видит фрагмент с ключом. Когда пользователь вставляет или переходит по полному URL, фрагмент остаётся в памяти браузера и обеспечивает клиентское дешифрование. Это архитектурно элегантный способ доставить разделяемую E2EE-ссылку без вспомогательного канала.

E2EE против серверного шифрования: проверка на модель угроз

Серверное шифрование защищает от одного сценария: физической кражи накопителя. Если диск украден, шифрование AES-256 at rest делает данные непрозрачными до компрометации KMS. Сквозное шифрование защищает от всего, что сервер мог бы сделать: судебного предписания, инсайдерского доступа, ransomware на живых данных или государственного принуждения. Если ваша модель угроз — «диск украли из дата-центра», серверного шифрования достаточно. Если это «правительство, противник или конкурент вынудит сервис выдать данные» — защитит только E2EE.

Аутентифицированное шифрование обязательно

Чистый AES-CBC без MAC допускает атаки типа padding oracle (BEAST, Lucky13), позволяющие расшифровать зашифрованный текст с помощью запросов с выбранным шифртекстом. Современная передача файлов должна использовать AEAD: AES-256-GCM (NIST SP 800-38D) или ChaCha20-Poly1305 (RFC 8439). Тег Poly1305 или тег GCM аутентифицирует зашифрованный текст и любые связанные данные (размер файла, nonce, заголовок имени файла). Если в процессе передачи изменится один бит, дешифрование завершится ошибкой. Тот, кто продолжает применять AES-CBC без HMAC в 2026 году, живёт в 2010-м.

Производство ключей для защищённых паролем передач

Когда пользователь вводит пароль для защиты передачи, нельзя использовать пароль напрямую как ключ AES: у него низкая энтропия, он уязвим к перебору. Современное производство ключей: PBKDF2-SHA-256 с 600 000 итераций (рекомендация OWASP 2023), scrypt с N=2^17 или Argon2id с 19 МиБ памяти и 2 итерациями. HexaTransfer использует PBKDF2 с 600 000 итераций. Tresorit использует Argon2id. Оба устойчивы к GPU-ускоренному взлому паролей. Провайдеры, до сих пор применяющие PBKDF2 с 10 000 итераций (рекомендация 2015 года), имеют недостаточный уровень защиты.

Сравнительная таблица

| Метод | Конфиденциальность | Аутентификация | Сервер видит открытый текст | Квантовая угроза | |---|---|---|---|---| | Только TLS 1.3 | При передаче | Да (MAC в наборе шифров) | Да | Обмен ключами под угрозой | | Серверное AES-256 | At rest + при передаче | Да | Да (есть ключ) | Низкая | | Клиентское AES-256-GCM | Полный путь | Да (тег GCM) | Нет | Низкая | | XChaCha20-Poly1305 | Полный путь | Да (тег Poly1305) | Нет | Низкая | | OpenPGP (Curve25519 + AES-256) | Полный путь | Да (MDC/OCB) | Нет | Curve25519 под угрозой |

Постквантовые соображения

Алгоритм Шора угрожает Curve25519 и RSA после появления крупных квантовых компьютеров. Симметричные шифры (AES-256, ChaCha20) ослабляются алгоритмом Гровера, но не взламываются: 256-битные ключи сохраняют 128-битную постквантовую стойкость, что по-прежнему недостижимо. NIST стандартизировал ML-KEM (Kyber) в 2024 году для постквантовой инкапсуляции ключей. Signal перешёл на PQXDH в 2023 году. Сервисы передачи файлов пока широко не приняли постквантовые методы, однако окно риска («перехватить сейчас, расшифровать позже») означает, что долгосрочные архивы уже сегодня должны использовать 256-битное симметричное шифрование.

Как выбрать метод

Разовая конфиденциальная передача, короткое время хранения: клиентское AES-256-GCM с ключами во фрагменте URL. Реализация — HexaTransfer. Рабочие процессы в регулируемых отраслях: XChaCha20-Poly1305 с журналами аудита (Tresorit). Несколько получателей с управлением ключами: OpenPGP (Proton Drive, GPG). Крупное децентрализованное распространение: libsodium secretbox плюс избыточное кодирование (Internxt на Storj). Нечувствительные данные с высокой нагрузкой: TLS + at-rest приемлем.

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