Шифрование простыми словами: от AES до постквантовой криптографии и сквозного шифрования

Каждое отправленное сообщение, каждый платёж и каждый введённый пароль опирается на шифрование. Это невидимый слой, который обеспечивает конфиденциальность цифровой жизни — и он встроен практически в каждое приложение, от которого зависит ваш бизнес. В этой статье мы разберём, как разные виды шифрования защищают реальные приложения, почему такие технологии, как эллиптические кривые и постквантовые алгоритмы, важны для ваших продуктов, и что решение Instagram* отказаться от сквозного шифрования говорит о противостоянии между приватностью и регулированием.

Что на самом деле делает шифрование

Шифрование превращает читаемые данные (открытый текст) в нечитаемую форму (шифротекст) с помощью секретного значения — ключа. Только тот, кто обладает правильным ключом, может обратить процесс и восстановить исходные данные.

Два свойства имеют наибольшее значение:

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

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

Симметричное шифрование: рабочая лошадка защиты данных

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

Где вы сталкиваетесь с ним каждый день

AES (Advanced Encryption Standard) — наиболее широко используемый симметричный шифр в мире. Принятый NIST в 2001 году, он поддерживает ключи длиной 128, 192 или 256 бит и имеет аппаратное ускорение практически в каждом современном процессоре.

Вот где AES защищает ваши данные на практике:

Облачное хранилище. Когда вы загружаете файлы в AWS S3, Google Cloud Storage или Azure Blob Storage, они шифруются при хранении с помощью AES-256. Даже если кто-то получит физический доступ к оборудованию, данные будут нечитаемы без ключа.
Шифрование баз данных. PostgreSQL, MongoDB и MySQL — все предлагают шифрование на основе AES для защиты данных на диске. Это означает, что украденная резервная копия базы данных бесполезна без ключей шифрования.
HTTPS / TLS. Каждый раз, когда ваш браузер показывает значок замка, основную работу выполняет AES. TLS 1.3 использует AES-GCM (Galois/Counter Mode) в качестве основного шифра — он одновременно шифрует данные и проверяет их целостность, защищая всё: от учётных данных до вызовов API.
Мобильные приложения. И файловое шифрование Android, и Data Protection от Apple используют AES-256 для шифрования данных на устройстве. Когда пользователь блокирует телефон, ключи шифрования удаляются из памяти, делая сохранённые данные недоступными.
Обработка платежей. PCI DSS — стандарт безопасности для обработки данных кредитных карт — требует шифрования AES для данных держателей карт как при передаче, так и при хранении.

ChaCha20-Poly1305 — ещё один симметричный шифр, набирающий популярность. Он быстрее AES на устройствах без аппаратного ускорения AES — особенно на старых смартфонах и IoT-устройствах. Google выбрал его для TLS-соединений на Android, и это шифр по умолчанию в WireGuard VPN.

Попробуйте сами: AES-шифрование в терминале

Никакого специального ПО не нужно — OpenSSL предустановлен в macOS, Linux и большинстве серверных сред. Откройте терминал и попробуйте эти команды.

Зашифровать сообщение с помощью AES-256:

echo "I want to secure my app with AES" | openssl enc -aes-256-cbc -a -salt -pass pass:nerdy_pro

На выходе будет блок случайного на вид Base64-текста — ваш зашифрованный текст. Чтобы расшифровать его, возьмите этот вывод и выполните:

echo "U2FsdGVkX181dnX8SWIhZTumWK0Uc7Kh947omVSNpH8lujB43L5OjlubfkGa3Y1dyxj5cfzyPZjhWiyGzIWdPw==" | openssl enc -aes-256-cbc -a -d -salt -pass pass:nerdy_pro

Вы получите исходное сообщение обратно. OpenSSL может показать предупреждение: *** WARNING : deprecated key derivation used. — это ожидаемо. Оно означает, что OpenSSL по умолчанию использует устаревший метод вывода ключа при использовании -pass pass:. В продакшене следует использовать -pbkdf2 для более надёжного вывода ключей, но для демонстрации стандартный метод подходит.

Теперь попробуйте изменить один символ в пароле и расшифровать снова — команда завершится с ошибкой. Это демонстрирует основное свойство симметричного шифрования: без точного ключа данные невосстановимы.

Вы также можете шифровать целые файлы:

# Зашифровать
openssl enc -aes-256-cbc -salt -in report.pdf -out report.pdf.enc -pass pass:nerdy_pro

# Расшифровать
openssl enc -aes-256-cbc -d -in report.pdf.enc -out report-decrypted.pdf -pass pass:nerdy_pro

Проблема распределения ключей

Симметричное шифрование быстрое и эффективное, но обе стороны должны иметь общий секретный ключ до начала коммуникации. Если ваше приложение обслуживает миллион пользователей, вы не сможете безопасно предварительно раздать миллион разных ключей. Эту проблему решает асимметричная криптография.

Асимметричное шифрование: доверие между незнакомцами

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

RSA: основа интернет-безопасности

RSA, опубликованный в 1977 году, стал первой практической системой с открытым ключом. Его безопасность основана на сложности факторизации произведения двух очень больших простых чисел — задача, которую легко поставить, но практически невозможно решить с помощью современных технологий.

Вот как RSA работает в реальных приложениях:

SSL/TLS-сертификаты. Когда вы посещаете сайт по HTTPS, сервер предъявляет сертификат, подписанный с помощью RSA (или ECC). Ваш браузер проверяет эту подпись, чтобы убедиться, что вы общаетесь с настоящим сервером, а не с самозванцем. Центры сертификации, такие как Let's Encrypt, выдают миллионы сертификатов с подписью RSA.
Подпись кода. Когда вы загружаете приложение из Apple App Store или устанавливаете Windows-приложение с цифровой подписью, подписи RSA подтверждают, что код не был изменён с момента публикации разработчиком.
Шифрование электронной почты. PGP/GPG и S/MIME используют RSA для шифрования писем и их подписи, обеспечивая как конфиденциальность, так и подлинность отправителя.
SSH-доступ. Системные администраторы используют пары ключей RSA для безопасного доступа к серверам без паролей — ssh-keygen -t rsa — одна из самых распространённых команд в любом DevOps-процессе.

Попробуйте сами: RSA-шифрование в терминале

Сгенерируйте пару ключей RSA:

# Сгенерировать 2048-битный закрытый ключ
openssl genrsa -out private.pem 2048

# Извлечь открытый ключ
openssl rsa -in private.pem -pubout -out public.pem

Теперь зашифруйте сообщение открытым ключом и расшифруйте закрытым:

# Зашифровать — это может сделать любой, у кого есть ваш открытый ключ
echo "I want to secure my app with RSA" | openssl pkeyutl -encrypt -pubin -inkey public.pem -out message.enc

# Расшифровать — это может сделать только владелец закрытого ключа
openssl pkeyutl -decrypt -inkey private.pem -in message.enc

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

Гибридный подход

На практике асимметричное шифрование слишком медленное для шифрования больших объёмов данных. Вместо этого реальные системы используют гибридный подход: RSA (или ECC) безопасно обменивается одноразовым симметричным ключом, а затем AES выполняет массовое шифрование данных на высокой скорости. Именно так работают TLS, SSH и PGP под капотом.

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

Криптография на эллиптических кривых (ECC) обеспечивает тот же уровень безопасности, что и RSA, но с значительно меньшими ключами. Это напрямую означает более быстрые соединения, меньшие сертификаты, меньшую пропускную способность и лучшую производительность на мобильных и IoT-устройствах.

Практическая разница

Уровень безопасности	Размер ключа RSA	Размер ключа ECC
Стандартный (128 бит)	3072 бит	256 бит
Высокий (192 бит)	7680 бит	384 бит
Ультра (256 бит)	15360 бит	521 бит

256-битный ключ ECC обеспечивает ту же защиту, что и 3072-битный ключ RSA — это уменьшение размера ключа в 12 раз. Для приложений, обрабатывающих тысячи соединений в секунду или работающих на устройствах с батарейным питанием, эта разница существенна.

Где ECC используется сегодня

TLS 1.3. Последняя версия TLS использует исключительно обмен ключами на основе ECC (ECDHE). Обмен ключами RSA полностью удалён. Каждое современное HTTPS-соединение использует эллиптические кривые.
Signal и WhatsApp. Протокол Signal использует Curve25519 — конкретную эллиптическую кривую, разработанную для высокой производительности и устойчивости к ошибкам реализации — для обмена ключами. Тот же протокол защищает сообщения более двух миллиардов пользователей WhatsApp.
WireGuard VPN. WireGuard использует Curve25519 для всех обменов ключами, что способствует его репутации более простого и быстрого VPN по сравнению с OpenVPN или IPsec.
SSH-ключи. Ed25519 — схема подписи на эллиптических кривых — стала рекомендуемым типом ключей для SSH. Она создаёт более короткие ключи и более быстрые подписи, чем RSA: ssh-keygen -t ed25519 генерирует ключ, который одновременно более безопасен и удобнее, чем старый RSA по умолчанию.
Криптовалюты. Bitcoin и Ethereum используют эллиптическую кривую secp256k1 для подписи каждой транзакции. Когда вы отправляете криптовалюту, подпись ECC доказывает, что вы владеете кошельком, не раскрывая ваш закрытый ключ.
Вход через Apple и Google. Sign in with Apple использует ECC (P-256) для токенов идентификации. Google Cloud KMS поддерживает ключи ECC для подписи и верификации.

Попробуйте сами: ключи ECC в терминале

Сгенерируйте пару ключей на эллиптических кривых и сравните с RSA:

# Сгенерировать закрытый ключ ECC (кривая P-256)
openssl ecparam -genkey -name prime256v1 -noout -out ec-private.pem

# Извлечь открытый ключ
openssl ec -in ec-private.pem -pubout -out ec-public.pem

# Сравнить размеры файлов — ключи ECC значительно меньше
wc -c private.pem ec-private.pem

Вы увидите, что закрытый ключ ECC примерно в 4–5 раз меньше, чем RSA, при эквивалентном уровне безопасности. На сервере, обрабатывающем тысячи TLS-рукопожатий в секунду, эта разница быстро накапливается.

Цифровые подписи и контрольные суммы: доказательство подлинности и целостности

Шифрование сохраняет данные в секрете, но остаются два не менее важных вопроса: кто отправил эти данные? и были ли они изменены при передаче? Цифровые подписи и контрольные суммы отвечают на эти вопросы — и они столь же фундаментальны для безопасности приложений, как и само шифрование.

Контрольные суммы и CRC: обнаружение случайных повреждений

Контрольная сумма — это короткое значение, вычисляемое из блока данных. Если хотя бы один бит данных изменится, контрольная сумма тоже изменится. Простейшая форма — CRC (циклический избыточный код) — быстрый алгоритм, предназначенный для обнаружения случайных ошибок при передаче или хранении данных.

Вы используете CRC чаще, чем можете подумать:

Загрузка файлов. Когда вы скачиваете образ Linux или программный пакет, на сайте часто указывается контрольная сумма SHA-256 или MD5. Вы вычисляете контрольную сумму загруженного файла и сравниваете — если они совпадают, файл прибыл без повреждений.
Сетевые протоколы. Ethernet-кадры, TCP-пакеты и ZIP-файлы — все включают CRC-контрольные суммы для обнаружения повреждений при передаче.
Репликация баз данных. Такие системы, как PostgreSQL, используют контрольные суммы для обнаружения повреждений данных на диске до того, как они распространятся на реплики.
Git. Каждый коммит, файл и дерево в Git-репозитории идентифицируются хешем SHA-1. Именно поэтому Git может обнаружить любую модификацию истории репозитория.

Попробуйте в терминале:

# Создать файл и вычислить его контрольную сумму SHA-256
echo "I want to secure my app with checksums" > document.txt
shasum -a 256 document.txt

# Измените хотя бы один символ, и контрольная сумма полностью изменится
echo "I want to secure my app with Checksums" > document.txt
shasum -a 256 document.txt

Две контрольные суммы будут совершенно разными — не слегка отличающимися, а полностью неузнаваемыми. Это свойство называется лавинным эффектом, и именно оно делает контрольные суммы надёжным инструментом обнаружения изменений.

Важное различие: CRC и простые контрольные суммы обнаруживают случайные повреждения — они не защищают от намеренной подмены. Злоумышленник, изменивший файл, может просто пересчитать контрольную сумму. Для защиты от умышленной модификации нужны криптографические подписи.

Цифровые подписи: доказательство авторства данных

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

Это даёт две гарантии:

Аутентификация — сообщение было создано владельцем закрытого ключа и никем другим.
Целостность — сообщение не было изменено после подписания.

Цифровые подписи повсюду в продакшен-системах:

Обновления ПО. Когда ваш телефон устанавливает обновление iOS или Android, ОС проверяет цифровую подпись Apple или Google перед применением. Модифицированное обновление без валидной подписи отклоняется — это основная защита от вредоносных прошивок.
Аутентификация API. JWT (JSON Web Token), используемые для аутентификации API, подписаны цифровой подписью. Когда ваш бэкенд получает JWT, он проверяет подпись, чтобы подтвердить, что токен был выдан вашим сервером аутентификации и не был изменён.
Пакетные менеджеры. npm, PyPI, Docker Hub и APT — все используют подписи для проверки того, что пакеты были опубликованы заявленными авторами. Атаки на цепочку поставок — вроде печально известного инцидента с event-stream — эксплуатируют пробелы в этой верификации.
Транзакции блокчейна. Каждая транзакция Bitcoin или Ethereum подписана закрытым ключом отправителя. Сеть проверяет подпись перед принятием транзакции — именно так криптовалюта работает без центрального органа.
Подписание документов. PDF-документы, контракты и счета могут нести цифровые подписи, подтверждающие авторство и обнаруживающие модификации — признанные юридически обязательными в большинстве юрисдикций в соответствии с eIDAS (ЕС) и ESIGN (США).

Попробуйте подписать и проверить сообщение самостоятельно:

# Создать документ
echo "I want to secure my app with digital signatures" > message.txt

# Подписать его вашим закрытым ключом RSA (из предыдущего примера)
openssl dgst -sha256 -sign private.pem -out message.sig message.txt

# Проверить подпись с помощью открытого ключа
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Вывод: Verified OK

# Теперь изменим файл и проверим снова
echo "I want to secure my app with Digital Signatures" > message.txt
openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
# Вывод: Verification Failure

Изменённое сообщение не проходит проверку — подпись доказывает и кто создал документ, и что он не был изменён. Этот же механизм защищает каждый HTTPS-сертификат, каждый подписанный Git-коммит и каждое приложение, которое вы устанавливаете из магазина приложений.

HMAC: подписи для симметричных систем

Когда обе стороны разделяют секретный ключ (как во многих API-интеграциях), HMAC (код аутентификации сообщений на основе хеша) обеспечивает целостность и аутентификацию без накладных расходов криптографии с открытым ключом. Stripe, AWS и GitHub — все используют HMAC для подписи вебхуков, чтобы ваш сервер мог подтвердить их подлинность:

# Вычислить HMAC-SHA256 сообщения
echo -n "I want to secure my app with HMAC" | openssl dgst -sha256 -hmac "nerdy_pro"

Ваш сервер вычисляет тот же HMAC, используя свою копию общего секрета, и сравнивает его с подписью в заголовке запроса. Если они совпадают, вебхук подлинный.

JWT: подписи на практике

JSON Web Token (JWT) — одно из самых распространённых практических применений цифровых подписей. Если в вашем приложении есть аутентификация пользователей, велика вероятность, что JWT задействованы. JWT — это компактный, URL-безопасный токен из трёх частей, разделённых точками: заголовок, полезная нагрузка и подпись.

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0Miwicm9sZSI6Im5lcmR5X2FkbWluIn0.oAi5ALawUM_KpWDkiJcfA8504oQ_Yjx7OhEM8nZxlIc

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

Попробуйте декодировать этот токен сами — вставьте его на jwt.io и посмотрите, что внутри. Вы заметите, что можете прочитать полезную нагрузку, не зная секрета. Это сделано намеренно: JWT подписаны, а не зашифрованы. Подпись лишь доказывает, что токен не был изменён — она не скрывает содержимое.

Алгоритмы подписи определяют модель безопасности:

HS256 (HMAC-SHA256) — симметричный. Один и тот же секретный ключ подписывает и проверяет токен. Прост в настройке, но каждый сервис, которому нужно проверять токены, должен иметь секрет — что становится риском по мере роста архитектуры.
RS256 (RSA-SHA256) — асимметричный. Сервер аутентификации подписывает закрытым ключом, а любой сервис проверяет открытым ключом. Открытый ключ можно свободно распространять без ущерба для безопасности.
ES256 (ECDSA-P256) — асимметричный, на основе эллиптических кривых. Та же модель доверия, что и RS256, но с меньшими ключами и более быстрыми подписями. Всё чаще рекомендуется для новых приложений.

Преимущества JWT:

Аутентификация без состояния. Серверу не нужно обращаться к базе данных или хранилищу сессий при каждом запросе — токен сам содержит всю необходимую информацию для авторизации пользователя. Это упрощает горизонтальное масштабирование на несколько серверов.
Межсервисное доверие. В микросервисной архитектуре сервис аутентификации подписывает токен один раз, и каждый нижестоящий сервис может независимо проверить его с помощью открытого ключа. Общая база данных или сетевой вызов не требуются.
Стандарт и портативность. JWT — это открытый стандарт (RFC 7519), поддерживаемый библиотеками на каждом основном языке программирования. Токены можно передавать в HTTP-заголовках, параметрах URL или cookie.

Подводные камни:

Токены нельзя отозвать. После подписания JWT действителен до истечения срока. Если аккаунт пользователя скомпрометирован, вы не можете аннулировать существующие токены без добавления серверного списка блокировки — что частично нивелирует преимущество отсутствия состояния. Короткое время жизни (15 минут) в сочетании с refresh-токенами смягчают эту проблему.
Полезная нагрузка не зашифрована. Полезная нагрузка в кодировке Base64 подписана, но не зашифрована — любой, кто перехватит токен, может прочитать его содержимое. Никогда не помещайте конфиденциальные данные (пароли, персональную информацию, API-ключи) в полезную нагрузку JWT. Если вам нужен зашифрованный токен, используйте JWE (JSON Web Encryption), хотя это добавляет сложности.
Атаки подмены алгоритма. Если сервер принимает несколько алгоритмов и не строго валидирует заголовок alg, злоумышленник может подделать токены — например, переключившись с RS256 на HS256 и подписав открытым ключом как HMAC-секретом. Всегда принудительно проверяйте ожидаемый алгоритм на стороне сервера.
Раздутые токены. Разработчики иногда помещают слишком много данных в полезную нагрузку — целые профили пользователей, списки прав, состояние сессии. JWT отправляются с каждым запросом, обычно в HTTP-заголовке. Большие токены увеличивают пропускную способность, могут превысить ограничения на размер заголовков и замедлить каждый API-вызов. Держите полезную нагрузку минимальной: ID пользователя, роль, время истечения.

Для большинства приложений JWT с подписью ES256 и коротким временем жизни обеспечивают хороший баланс безопасности, производительности и простоты. Если вам нужен отзыв токенов, сочетайте их с лёгкой серверной проверкой по списку отзыва или используйте непрозрачные refresh-токены, которые можно отозвать независимо.

Квантовая угроза: реальный риск, требующий подготовки уже сейчас

Квантовые компьютеры используют принципиально иную физику — кубиты, способные находиться в нескольких состояниях одновременно — для решения определённых задач экспоненциально быстрее любого классического компьютера. Для шифрования это имеет конкретные и хорошо изученные последствия.

Что квантовые компьютеры сломают

В 1994 году Питер Шор опубликовал квантовый алгоритм, доказавший, что достаточно мощный квантовый компьютер сможет взломать RSA, ECC и Диффи-Хеллмана — по сути, каждый асимметричный алгоритм, используемый сегодня. Это не теоретические предположения: это доказанный математический результат. Открытым остаётся лишь вопрос, когда квантовое оборудование станет достаточно мощным для выполнения алгоритма в масштабе.

Симметричные шифры, такие как AES, затронуты менее серьёзно. Алгоритм Гровера фактически вдвое снижает безопасность симметричных ключей — делая AES-128 недостаточным, но оставляя AES-256 с комфортным 128-битным запасом безопасности.

«Собери сейчас, расшифруй потом»

Именно эта угроза делает квантовые вычисления актуальной проблемой сегодня, а не в далёком будущем. Спецслужбы и продвинутые злоумышленники уже перехватывают и сохраняют зашифрованный трафик, планируя расшифровать его, когда квантовое оборудование созреет. Эта стратегия хорошо задокументирована в руководстве АНБ по постквантовой кибербезопасности.

Для любого приложения, обрабатывающего данные с длительным сроком конфиденциальности — медицинские записи, финансовые данные, юридические коммуникации, интеллектуальная собственность — это реальный риск уже сейчас, а не гипотетический.

Постквантовая криптография: ответ индустрии

В 2024 году NIST утвердил первые постквантовые криптографические стандарты:

ML-KEM (CRYSTALS-Kyber) — механизм обмена ключами, заменяющий ECDH. Уже развёрнут в продакшене: Chrome и Cloudflare используют гибридный обмен ключами X25519 + ML-KEM по умолчанию.
ML-DSA (CRYSTALS-Dilithium) — схема цифровой подписи, заменяющая подписи RSA и ECDSA.
SLH-DSA (SPHINCS+) — резервная схема подписи на основе хеш-функций, обеспечивающая алгоритмическое разнообразие на случай, если решётчатые схемы окажутся уязвимыми.

Что это значит для ваших приложений

Если вы создаёте или поддерживаете приложения сегодня, вот что имеет значение:

Переходите на AES-256. Это самый простой шаг, обеспечивающий квантово-устойчивое симметричное шифрование практически без потери производительности.
Включите гибридный обмен ключами. Современные библиотеки TLS (OpenSSL 3.x, BoringSSL) уже поддерживают X25519 + ML-KEM. Его включение защищает соединения как от классических, так и от квантовых атак.
Проведите аудит криптографических зависимостей. Знайте, где в вашем стеке используются RSA и ECC — это компоненты, которые в конечном итоге потребуют миграции.
Планируйте с учётом бо́льших ключей и подписей. Постквантовые алгоритмы создают более крупные ключи, чем ECC. Проверьте, что ваши протоколы, сертификаты и хранилища могут их вместить.

Сквозное шифрование: золотой стандарт приватных сообщений

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

Как работает современное E2EE на практике

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

Обмен ключами на эллиптических кривых (Curve25519) — два устройства устанавливают общий секрет, не передавая его по сети.
Алгоритм Double Ratchet — генерирует новый ключ шифрования для каждого отдельного сообщения. Если злоумышленник каким-то образом получит один ключ, он не сможет расшифровать прошлые или будущие сообщения. Это свойство называется прямой секретностью (forward secrecy).
AES-256 или ChaCha20 — шифрует фактическое содержимое сообщения на высокой скорости.
Аутентификация HMAC — гарантирует, что сообщения не могут быть изменены при передаче.

В результате каждое сообщение имеет уникальный ключ, ключи никогда не используются повторно, а компрометация любого отдельного ключа локализована. Именно поэтому исследователи безопасности стабильно рекомендуют протокол Signal как эталон безопасности обмена сообщениями.

Проблема групповых чатов

E2EE в диалогах один на один — решённая задача. Групповые чаты значительно сложнее. Когда в группе 50, 200 или 1000 участников, протокол должен справляться с рядом дополнительных сложностей:

Распределение ключей в масштабе. Каждое сообщение должно быть зашифровано так, чтобы все текущие участники группы — и только текущие участники — могли его прочитать. Протокол Signal использует механизм Sender Keys: каждый участник делится симметричным ключом с группой, и сообщения шифруются один раз, а не по разу для каждого получателя. Это обеспечивает производительность групповых чатов даже при большом количестве участников.
Изменение состава. Когда кто-то присоединяется к группе или покидает её, ключи шифрования должны быть ротированы, чтобы новый участник не мог прочитать прошлые сообщения, а ушедший — будущие. WhatsApp и Signal делают это автоматически, но это добавляет задержку и накладные расходы — особенно в больших группах с частыми изменениями состава.
Поддержка нескольких устройств. Если у пользователя есть телефон, планшет и десктопный клиент, каждое устройство имеет собственные ключи шифрования. Протокол должен обеспечить расшифровку групповых сообщений на всех устройствах, сохраняя при этом прямую секретность. Протокол iMessage от Apple и мультиустройственная архитектура Signal решают этот компромисс по-разному.

Для бизнесов, создающих функции группового взаимодействия — командные чаты, каналы проектов, общие рабочие пространства — это не теоретические проблемы. Архитектурные решения, принятые на ранних этапах разработки, определяют, будет ли E2EE осуществимо в том масштабе, который в конечном итоге потребуется продукту.

Отказ Instagram от E2EE: поучительная история

В декабре 2023 года Meta* развернула сквозное шифрование по умолчанию в Messenger и начала распространять его на личные сообщения Instagram. Инженерные усилия были масштабными — команда Meta описала многолетнюю перестройку инфраструктуры, необходимую для того, чтобы перестроить такие функции, как поиск, превью ссылок и обнаружение спама, без серверного доступа к содержимому сообщений.

Затем, в марте 2026 года, Meta сделала шаг назад. Компания объявила, что Instagram удалит E2EE из личных сообщений 8 мая 2026 года. В отличие от WhatsApp, где E2EE включено по умолчанию для всех пользователей, зашифрованные сообщения Instagram были доступны только как опция для активации в отдельных регионах — и Meta сослалась на низкое использование как причину отключения.

Этот разворот значим по нескольким причинам:

Приватность как функция, а не гарантия. E2EE в Instagram никогда по-настоящему не было «по умолчанию» — пользователям приходилось включать его для каждого чата, и оно было доступно только в определённых странах. Это разительно контрастирует с WhatsApp, где каждое сообщение зашифровано сквозным шифрованием с 2016 года без каких-либо действий пользователя. Урок: если шифрование не включено по умолчанию, уровень его использования останется низким, и этот низкий уровень станет оправданием для удаления.

Давление регуляторов побеждает. Правительства США, Великобритании, ЕС и Австралии активно выступают против E2EE в мессенджерах, утверждая, что оно препятствует расследованиям по делам о сексуальной эксплуатации детей и терроризме. Online Safety Act Великобритании включает положения, которые могут потребовать от платформ нарушить E2EE. Предложенный ЕС регламент «Chat Control» обязал бы проводить сканирование сообщений на стороне клиента перед шифрованием. Удаление E2EE из Instagram DM позволяет Meta сканировать сообщения на предмет материалов сексуального насилия над детьми (CSAM) и другого вредоносного контента — в соответствии с ожиданиями регуляторов.

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

Ландшафт E2EE сегодня. Вот как выглядят крупные платформы после разворота Instagram:

Платформа	E2EE по умолчанию	Протокол
Signal	Да (всегда)	Signal Protocol
WhatsApp	Да (с 2016)	Signal Protocol
iMessage	Да	Собственный протокол Apple
Instagram DM	Удалено (май 2026)	Н/Д
Telegram	Нет (только «Секретные чаты» по выбору)	MTProto
Discord	Нет	Н/Д (шифрование только при передаче)

Разрыв между платформами, для которых шифрование — это основное архитектурное обязательство (Signal, WhatsApp, iMessage), и теми, где оно — опциональная функция (Instagram, Telegram, Discord), никогда не был столь очевиден. Для бизнесов, создающих функции обмена сообщениями, это ключевое проектное решение: E2EE должно быть фундаментальным, а не прикрученным — потому что опциональное шифрование можно отобрать.

Чего не защищает E2EE

Для любого приложения, реализующего или использующего E2EE, важно понимать его ограничения:

Метаданные. E2EE защищает содержимое, но не метаданные. Платформа по-прежнему знает, кто писал кому, когда, как часто и с какого IP-адреса. Исследования EFF показали, что одних метаданных достаточно для выявления конфиденциальной информации о связях и моделях поведения.
Компрометация конечного устройства. Если само устройство скомпрометировано — вредоносным ПО, шпионскими программами вроде Pegasus или физическим доступом — злоумышленник читает сообщения после расшифровки. E2EE защищает данные при передаче и на сервере, но не на скомпрометированном устройстве.
Облачные резервные копии. Если резервные копии чатов хранятся без шифрования в iCloud или Google Drive, E2EE фактически обходится. WhatsApp предлагает зашифрованные резервные копии, но пользователи должны включить их вручную.
Человеческий фактор. Никакой криптографический протокол не помешает получателю сделать снимок экрана или быть обманутым методами социальной инженерии для передачи переписки.

Как всё это работает вместе в реальном приложении

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

Криптография на эллиптических кривых устанавливает доверие между сторонами и безопасно обменивается ключами — с меньшими и более быстрыми ключами, чем устаревшие подходы на основе RSA.
Симметричное шифрование (AES-256) выполняет высокоскоростное шифрование фактических данных — файлов, сообщений, записей баз данных, данных API.
Цифровые подписи и контрольные суммы доказывают подлинность и обнаруживают подмену — от подписанных API-токенов и обновлений ПО до верифицированных вебхуков.
Сквозное шифрование гарантирует, что даже оператор сервиса не может получить доступ к пользовательскому контенту — это критически важно для здравоохранения, юридических технологий, финансов и любого приложения, где конфиденциальность пользователей — это регуляторное или конкурентное требование.
Готовность к постквантовой эре защищает долгоживущие данные от будущих угроз — вопрос, которым дальновидные компании занимаются уже сейчас.

Правильная стратегия шифрования зависит от того, что вы создаёте: мобильное приложение, обрабатывающее персональные данные, B2B-платформу для финансовых записей, функцию обмена сообщениями или IoT-систему. У каждого свои модели угроз и регуляторные требования, и архитектура шифрования должна им соответствовать.

Источники

Shor, P. (1994). Algorithms for quantum computation: discrete logarithms and factoring. Proceedings 35th Annual Symposium on Foundations of Computer Science.
Grover, L. (1996). A fast quantum mechanical algorithm for database search. arXiv.
Cohn-Gordon, K. et al. (2016). A formal security analysis of the Signal messaging protocol. Cryptology ePrint Archive.
NIST (2024). Post-Quantum Encryption Standards.
NSA (2022). Post-Quantum Cybersecurity Resources.
Meta Engineering (2024). End-to-end encryption on Messenger.
EFF (2013). Why metadata matters.
Citizen Lab (2021). Hooking Candiru: another mercenary spyware vendor comes into focus.

*Meta Platforms Inc. признана экстремистской организацией, её деятельность запрещена на территории Российской Федерации. Instagram и Facebook являются продуктами Meta Platforms Inc.