Как работает сквозное шифрование при передаче файлов
Разберитесь, как сквозное шифрование защищает ваши файлы при передаче. Технический разбор криптографических протоколов и реализации.
Сквозное шифрование при передаче файлов означает, что байты, покидающие ваше устройство, зашифрованы ключом, который никогда не касается сервера, а расшифровать их может только ваш адресат. Сервер хранит шифротекст, ничего значимого не видит и может быть взломан без раскрытия содержимого файла. Криптографический рецепт почти всегда включает симметричный шифр — AES-256-GCM или XChaCha20-Poly1305 — для самого файла, обёрнутый обменом ключами X25519 ECDH или RSA-OAEP 2048/4096 для ключевого материала. Вот как это работает на практике.
Какие угрозы на самом деле устраняет E2EE
E2EE специально защищает от: взлома, получения судебного предписания или вредоносных действий со стороны провайдера передачи; перехвата сетевыми атакующими трафика после расшифровки TLS на прокси; попадания резервных снимков бакета хранилища в чужие руки; и инсайдерского доступа сотрудников сервиса. Оно не защищает от вредоносного ПО на устройстве отправителя или получателя, фишинга, перехватывающего ссылку для расшифровки, или скомпрометированных аккаунтов получателей. Понимание модели угроз важно, потому что «зашифровано» часто неправильно используется для обозначения «TLS при передаче плюс AES в покое на сервере» — это означает, что провайдер держит ключи.
Симметричное шифрование для полезной нагрузки файла
Файлы шифруются симметричным алгоритмом, потому что криптография с открытым ключом слишком медленна для массовых данных. Современный выбор — AES-256-GCM, определённый в NIST SP 800-38D, обеспечивающий конфиденциальность и аутентифицированную целостность за один проход. Случайный 256-битный ключ и уникальный 96-битный nonce (никогда не повторяемый с тем же ключом) защищают каждый файл. XChaCha20-Poly1305, определённый в RFC 8439 и RFC 8103, — альтернатива, часто более быстрая на устройствах без аппаратного ускорения AES-NI, например старых процессорах ARM. Оба алгоритма производят шифротекст плюс 128-битный тег аутентификации, обнаруживающий любое изменение данных.
Получение ключа из пароля
Когда E2EE использует пароль, сам пароль никогда не является ключом шифрования — это было бы слишком слабо против перебора. Вместо этого функция формирования ключа — PBKDF2-HMAC-SHA256 с 600 000 и более итерациями (рекомендации OWASP 2025), Argon2id с m=19 МиБ и t=2 (RFC 9106) или scrypt (RFC 7914) — «растягивает» пароль в сильный ключ. Случайная 128-битная или 256-битная соль предотвращает атаки с использованием радужных таблиц. Полученный ключ шифрует файл. Соль и количество итераций хранятся вместе с шифротекстом, чтобы получатель мог воссоздать ключ при вводе пароля.
Обёртка с открытым ключом для аккаунтных передач
Когда у получателей есть аккаунты с опубликованными открытыми ключами, ввод пароля не нужен. Отправитель генерирует случайный ключ шифрования файла (FEK), шифрует файл AES-256-GCM с FEK, затем шифрует FEK на открытый ключ каждого получателя через согласование ключей X25519 ECDH по RFC 7748 в сочетании с HKDF-SHA256 по RFC 5869 для получения ключа обёртки, или RSA-OAEP по PKCS#1 v2.2 с SHA-256. Обёрнутый FEK хранится рядом с шифротекстом. Только обладатель закрытого ключа получателя может развернуть FEK и расшифровать файл. Это модель Signal и Telegram для сообщений, адаптированная для файловых полезных нагрузок.
E2EE на основе ссылок с использованием фрагментов URL
В браузерных передачах применяется умный приём: ключ расшифровки хранится во фрагменте URL (части после #). Фрагменты никогда не отправляются серверу в HTTP-запросе. Ссылка вида https://example.com/d/abc123#k=B9kZtR... несёт ID файла на стороне сервера и ключ на стороне клиента. Браузер скачивает шифротекст, читает фрагмент в JavaScript и расшифровывает локально. Сервис никогда не видит ключ. Загвоздка в том, что если ссылка утечёт — в логах, на скриншотах, в предпросмотрах мессенджеров — ключ утечёт вместе с ней.
Целостность через AEAD и хеши
Режимы аутентифицированного шифрования с ассоциированными данными (AEAD), такие как GCM и ChaCha20-Poly1305, предотвращают подделку. Один перевёрнутый бит в шифротексте вызывает сбой проверки тега аутентификации, и функция расшифровки возвращает ошибку вместо мусорного открытого текста. Поверх AEAD многие реализации вычисляют SHA-256 или BLAKE3-хеш открытого текста как запись манифеста, чтобы получатель мог верифицировать после расшифровки соответствие файла намерениям отправителя. Это важно для больших файлов, передаваемых чанками, где частичная доставка иначе могла бы молча завершиться без хвоста.
Чанковое шифрование для больших файлов
Шифрование файла в 10 ГБ за одну операцию AES-GCM требует 10 ГБ в памяти — для браузеров это нереально. Реальные реализации разбивают файл на чанки, как правило 1–16 МБ каждый, и шифруют каждый независимо с производным подключом и nonce на основе счётчика. Инструмент шифрования age (age-encryption.org) использует чанки по 64 КБ с ChaCha20-Poly1305. Протокол Magic Wormhole использует потоковую конструкцию. Границы чанков также позволяют браузерам потоково расшифровывать через Streams API — начинать запись на диск до получения всего файла — и поддерживают возобновляемые загрузки при сетевых сбоях.
Транспортная безопасность поверх E2EE
TLS 1.3, определённый в RFC 8446, по-прежнему важен поверх E2EE — не для конфиденциальности полезной нагрузки (она уже зашифрована), а для приватности метаданных: имён файлов, размеров и временного паттерна. TLS 1.3 с прямосекретным обменом ключами X25519 означает, что даже при компрометации долгосрочного ключа сервера в будущем записанные сессии расшифровать не удастся. Закрепление сертификата или предзагрузка HSTS предотвращают атаки понижения версии. Вместе E2EE и TLS 1.3 защищают как содержимое файла, так и операционный паттерн того, кто что кому отправляет.
Типичные ошибки реализации
Три ошибки повторяются постоянно. Первая: повторное использование nonce с тем же ключом в AES-GCM катастрофически нарушает конфиденциальность — всегда используйте свежий случайный nonce или счётчик, никогда не повторяющийся. Вторая: реализация криптографии собственными процедурами вместо проверенных библиотек — libsodium, Web Crypto API (SubtleCrypto) или BoringSSL; операции в постоянном времени важны для предотвращения атак по времени. Третья: отсутствие аутентификации метаданных файла вместе с содержимым — если идентификатор отправителя, имя файла или список получателей не включены в AAD (Associated Authenticated Data), атакующий может незаметно подменить метаданные. HexaTransfer решает эти проблемы, используя стандартные примитивы Web Crypto на стороне клиента с проверенными паттернами.
Как проверить, действительно ли сервис использует E2EE
Читайте маркетинговые заявления скептически. Настоящий E2EE означает, что провайдер не может расшифровать файлы даже по судебному решению. Ищите опубликованную техническую документацию с точными алгоритмами (AES-256-GCM, X25519, HKDF, количество итераций PBKDF2), код клиента с открытым исходным кодом для аудита и модель угроз, признающую, что E2EE защищает, а что нет. Сервисы, предлагающие серверное восстановление пароля для зашифрованных файлов, не реализуют настоящий E2EE — они держат ключи. Сервисы, заявляющие «нулевые знания», должны подкреплять это описанием криптографического протокола, а не просто слоганом.
Попробуйте на hexatransfer.com — бесплатно, без аккаунта, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл