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

Ключевые выводы

  • E2EE устанавливается через протокол согласования ключей, а не общий пароль — рукопожатие X3DH протокола Signal позволяет двум устройствам договориться об общем секрете, даже если одно из них в этот момент офлайн.
  • Как только сессия установлена, алгоритм Double Ratchet выводит совершенно новый ключ для каждого сообщения, обеспечивая прямую секретность (forward secrecy) — прошлые сообщения остаются в безопасности, даже если ключ утёк, — и посткомпрометационную безопасность (post-compromise security) — сессия самовосстанавливается после компрометации.
  • Групповые чаты не могут просто масштабировать одно и то же попарное рукопожатие — Sender Keys жертвуют небольшой долей прямой секретности ради того, чтобы шифровать каждое сообщение один раз, а не по разу для каждого получателя.
  • E2EE защищает содержимое, а не метаданные — кто с кем общался, когда и как часто, в большинстве реализаций по-прежнему видно серверу.
  • Самая сложная нерешённая проблема в продакшен-реализациях E2EE — не криптография, а верификация ключей: доказать, что полученный вами открытый ключ действительно принадлежит вашему контакту, а не злоумышленнику посередине.

Что на самом деле означает «установление» шифрования

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

Механизм, который использует практически каждый современный защищённый мессенджер, — это протокол Signal, разработанный Тревором Перрином и Мокси Марлинспайком. На нём работают сам Signal, WhatsApp* и зашифрованный уровень Google Messages (RCS). Его рукопожатие называется X3DH — Extended Triple Diffie-Hellman (расширенный тройной Диффи-Хеллман) — и оно решает проблему, которую обычный обмен по Диффи-Хеллману решить не может: начать сессию с тем, кто прямо сейчас не в сети.

Рукопожатие X3DH: договориться о секрете с тем, кто офлайн

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

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

  1. Идентификационный ключ (IK) — долгосрочная пара ключей, идентифицирующая устройство. Она редко меняется, и именно её в конечном счёте проверяет верификация кода безопасности.
  2. Подписанный предварительный ключ (SPK) — среднесрочная пара ключей, периодически обновляемая (спецификация X3DH предлагает интервал порядка нескольких недель — до месяца), подписанная идентификационным ключом, чтобы получатель мог убедиться, что он действительно пришёл от этого устройства.
  3. Одноразовые предварительные ключи (OPK) — набор одноразовых пар ключей. Сервер выдаёт по одному на каждую новую входящую сессию и удаляет его после использования, а каждое устройство периодически загружает новые, чтобы пополнить запас.

Когда Алиса хочет впервые написать Бобу, она получает один из этих наборов с сервера (никогда закрытый ключ — только открытые половины). Затем она вычисляет три или четыре отдельных обмена по Диффи-Хеллману между комбинациями своих ключей и ключей Боба:

  • DH1 = её идентификационный ключ с подписанным предварительным ключом Боба
  • DH2 = её эфемерный (только что сгенерированный, одноразовый) ключ с идентификационным ключом Боба
  • DH3 = её эфемерный ключ с подписанным предварительным ключом Боба
  • DH4 = её эфемерный ключ с одноразовым предварительным ключом Боба, если он был доступен

Она объединяет результаты и пропускает их через функцию вывода ключа (HKDF), чтобы получить единый общий секрет. Боб, когда выходит в сеть, располагает всеми закрытыми половинами, необходимыми, чтобы вычислить точно такое же значение самостоятельно — DH коммутативен именно так, чтобы это работало. Ни одна из сторон никогда не передаёт сам секрет — каждая независимо вычисляет одно и то же число из смеси долгосрочных, среднесрочных и одноразовых ключей.

Почему четыре отдельных вычисления DH вместо одного? Каждое даёт конкретное свойство:

  • DH1 и DH2 привязывают сессию к долгосрочным идентичностям обеих сторон — именно это делает обмен аутентифицированным, а не просто секретным.
  • DH3 (и DH4, если был доступен одноразовый ключ) добавляют свежий, одноразовый материал, так что если долгосрочный идентификационный ключ будет скомпрометирован позже, прошлые сессии, согласованные до компрометации, невозможно будет пересчитать. Это зачаток прямой секретности ещё до того, как запустится ратчет.
  • Одноразовый предварительный ключ специально защищает от сервера, который лжёт о подписанном предварительном ключе — использование каждого OPK ровно один раз ограничивает то, сколько может повторно воспроизвести вредоносный или скомпрометированный сервер.

Результат X3DH — единый 256-битный общий секрет. Сам по себе, если использовать этот единственный секрет для каждого сообщения на протяжении всей жизни разговора, это была бы ровно та проблема «один утёкший ключ раскрывает всё», с которой начиналась эта статья. Этот секрет — не конец истории, а зерно для Double Ratchet.

Double Ratchet: новый ключ для каждого сообщения

Трещотка (ratchet) механически крутится только в одну сторону. Алгоритм Double Ratchet заимствует это название намеренно: состояние шифрования движется только вперёд, и нет способа отмотать его назад, чтобы восстановить прошлый ключ из более позднего.

Он сочетает два ратчета, работающих вместе:

Симметричный ключевой ратчет. Каждая сторона хранит «цепочечный ключ» (chain key). Каждый раз при отправке сообщения текущий цепочечный ключ пропускается через хеш-функцию (HMAC), чтобы получить два значения: ключ сообщения, используемый для шифрования этого одного сообщения и затем отбрасываемый, и новый цепочечный ключ, который заменяет старый. Ключи сообщений никогда не используются повторно и не могут быть выведены друг из друга в обратном порядке — хеш-функция работает только вперёд. Если злоумышленник записывает шифротекст, а затем крадёт цепочечный ключ, он сможет расшифровать все сообщения, отправленные после этого момента, но ничего до него.

Ратчет Диффи-Хеллмана. У одного симметричного ратчета всё ещё есть слабое место: украденный цепочечный ключ бессрочно компрометирует всё, что будет отправлено дальше. Чтобы это исправить, каждый раз, когда разговор «поворачивается» — примерно каждый раз, когда собеседник отвечает, — каждая сторона генерирует новую эфемерную пару ключей DH, выполняет новый обмен по Диффи-Хеллману с последним открытым ключом собеседника и подмешивает результат в цепочечный ключ. Это означает, что в систему на регулярной основе поступает новая порция свежей, непредсказуемой энтропии, которую злоумышленник не может ни предсказать, ни вычислить заранее.

Их сочетание даёт две отдельные гарантии, которые часто путают, хотя это не одно и то же:

  • Прямая секретность (forward secrecy) — компрометация сегодняшнего ключа не раскрывает вчерашние сообщения. Обеспечивается симметричным ратчетом: старые цепочечные ключи уже прохешированы вперёд и отброшены.
  • Посткомпрометационная безопасность (post-compromise security; в спецификации Double Ratchet она называется «восстановлением после взлома», break-in recovery, а неформально — «самовосстановлением») — компрометация сегодняшнего ключа не раскрывает и завтрашние сообщения, потому что следующий шаг DH-ратчета вносит новую случайность, которую злоумышленник никогда не видел. Обеспечивается DH-ратчетом.

Вместе они означают, что единичная компрометация в конкретный момент времени — украденное устройство, ключ, полученный под принуждением, — имеет ограниченный радиус поражения, а не приводит к постоянному взлому. Разговор самовосстанавливается в течение одного-двух сообщений благодаря свежим обменам DH, и это принципиально иная модель безопасности, чем «ключ скомпрометирован — разговор скомпрометирован навсегда».

Групповые сообщения: почему попарный протокол не масштабируется

X3DH вместе с Double Ratchet описывает сессию один на один. У группы из 200 человек нет «одной сессии» — есть до 200×199 потенциальных попарных сессий, и шифрование каждого сообщения по разу на получателя означало бы 200 отдельных операций шифрования (и в 200 раз больше трафика) для одного-единственного сообщения.

Ответ Signal — Sender Keys. Вместо попарных ратчетов между каждым участником каждый участник генерирует один симметричный «ключ отправителя» и раздаёт его всем остальным участникам группы индивидуально, через уже установленные попарные сессии Double Ratchet (это первоначальное распространение — дорогая часть, выполняемая при каждом изменении состава участников). После этого отправитель шифрует групповое сообщение ровно один раз своим ключом отправителя, и каждый участник, получивший этот ключ, может расшифровать его напрямую — без шифрования для каждого получателя на горячем пути.

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

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

Всё вышеописанное предполагает, что Алиса действительно получила от сервера открытые ключи именно Боба, а не злоумышленника. Если сервер (или кто угодно, способный действовать от его имени) выдаст Алисе набор ключей, контролируемый злоумышленником, X3DH отработает идеально и выдаст абсолютно валидный общий секрет — но не с тем человеком. Это классическая атака «человек посередине» (man-in-the-middle), и никакая математика вывода ключей её не исправит, потому что эта математика никогда не проверяет, чей именно ключ она получила.

Смягчение этой проблемы — верификация вне канала: Signal и WhatsApp* отображают код безопасности (safety number) — отпечаток, выведенный из идентификационных ключей обеих сторон, — который пользователи могут сверить лично, по голосовой связи или отсканировав QR-код. Если числа совпадают, идентификационные ключи подлинные и никто не перехватывает обмен. Этот шаг необязателен, большинство пользователей никогда его не выполняют, и именно этот пробел — а не криптография — является местом, где на практике происходят реалистичные атаки на E2EE-мессенджеры: скомпрометированный или принуждённый к сотрудничеству сервер распространения ключей, а не взломанный шифр.

Что это даёт, а что — нет

Плюсы:

  • Конфиденциальность переживает компрометацию сервера. Поскольку сервер хранит только шифротекст (а в X3DH — ещё и открытые ключи), взломанная база данных, резервная копия, изъятая по повестке, или недобросовестный сотрудник не могут раскрыть содержимое сообщений — раскрывать попросту нечего.
  • Прямая секретность ограничивает ущерб от кражи ключа. Украденное устройство или скомпрометированный долгосрочный ключ не открывает задним числом всю историю сообщений пользователя.
  • Посткомпрометационная безопасность означает, что система восстанавливается. В отличие от единственного статического ключа, скомпрометированная сессия Double Ratchet восстанавливается в течение нескольких сообщений.
  • Групповые сообщения масштабируются без повторного шифрования для каждого получателя благодаря Sender Keys — приемлемая производительность при таких размерах групп, где попарное шифрование бы не справилось.

Минусы:

  • Метаданные остаются нетронутыми. Сервер по-прежнему видит, кто кому пишет, как часто, с какого IP-адреса и как долго — исследования стабильно показывают, что одни метаданные раскрывают конфиденциальные модели отношений и поведения, иногда даже надёжнее, чем содержимое.
  • Компрометация конечного устройства обходит всё. E2EE защищает данные при передаче и на сервере — но не на устройстве, уже скомпрометированном вредоносным ПО или физическим доступом. Расшифрованные сообщения по определению читаемы на устройстве, которое их расшифровало.
  • Верификация ключей ручная и в основном пропускается. Протокол настолько же надёжен, насколько надёжно его самое слабое звено, а для большинства пользователей это звено — «я никогда не проверял код безопасности».
  • Дорого пристраивать постфактум. Функции, которые предполагают видимость на стороне сервера — поиск, обнаружение спама, превью ссылок, модерация контента, резервное копирование, — приходится перестраивать или перепроектировать вокруг шифротекста, который сервер не может прочитать. Это ровно та миграция, которую инженерная команда Meta* задокументировала для Messenger, и именно поэтому отказ Instagram* в 2026 году от E2EE в личных сообщениях был продуктовым и регуляторным решением, а не криптографическим — механизм, который описывает эта статья, уже был построен и работал. Мы разбираем этот разворот и то, как E2EE сочетается с AES, TLS и постквантовой криптографией в более широкой архитектуре безопасности, в статье «Шифрование простыми словами».
  • Изменения состава группы стоят реальной криптографической работы. Удаление участника требует ротации и повторного распространения ключей отправителя, а не переключения флага доступа.

Проектировать заранее, а не пристраивать потом

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

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

Источники

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