Раздел 15. Signal Protocol, X3DH и установка ключей из названия

В Разделе 14 мы выяснили, что сквозное шифрование — E2EE (End-to-End Encryption, «шифрование от конца до конца») — это когда только отправитель и получатель могут прочитать сообщение, а сервер видит лишь кашу из байтов. Но возникает вопрос: чтобы зашифровать сообщение только для Боба, Алисе нужен общий с ним секретный ключ. Откуда он у неё берётся? Этот раздел — про то, как два устройства добывают такой ключ. Без тяжёлой математики, только смысл.

В чём, собственно, сложность

Алисе и Бобу нужен общий секретный ключ, который знают только они. Но всё против этого:

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

Итого задача: как договориться об общем секрете, не встречаясь, не доверяя ключ серверу и не будучи онлайн в один момент. Звучит как фокус — но он существует.

Главный трюк: обмен ключами Диффи — Хеллмана

В основе лежит математический приём — обмен ключами Диффи — Хеллмана, DH (Diffie–Hellman, по фамилиям авторов). Суть без формул:

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

Классическая аналогия — смешивание красок. У каждого есть свой секретный цвет. Вы открыто обмениваетесь смесями (публичные части), затем каждый домешивает свой секретный цвет — и у обоих получается одинаковая итоговая краска. А наблюдатель, видевший только смеси, не сможет «разделить» их обратно и узнать секретные цвета.

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

Проблема «Боб офлайн» и prekeys

Обычный обмен Диффи — Хеллмана требует, чтобы оба были онлайн и обменялись публичными частями вживую. Но Боб спит. Как договориться с тем, кого нет в сети?

Решение — prekeys («предварительные ключи», заранее загруженные публичные ключи). Работает так:

1. Боб заранее, ещё когда был онлайн, загрузил на сервер пачку своих публичных ключей — это и есть prekeys. Они просто лежат там и ждут.
2. Алиса хочет написать офлайн-Бобу. Она берёт с сервера его prekeys, комбинирует со своими ключами — и сразу вычисляет общий секрет, не дожидаясь Боба.
3. Алиса шифрует первое сообщение этим секретом и отправляет. К сообщению прикладываются её публичные части.
4. Боб выходит в сеть, берёт свои приватные части и публичные части Алисы — и вычисляет тот же самый общий секрет, которым расшифровывает сообщение.

То есть prekeys — это способ провести «рукопожатие» с тем, кто сейчас офлайн. Прямое продолжение асинхронной логики из Раздела 5.

Что такое X3DH

Вся эта процедура установки первого ключа называется X3DH (Extended Triple Diffie–Hellman — «расширенный тройной обмен ключами Диффи — Хеллмана»). «Тройной» — потому что она комбинирует несколько таких публично-приватных пар сразу: это даёт и крепкий общий секрет, и заодно проверку, что ты говоришь с тем самым человеком. Без математики X3DH — это просто рецепт (протокол), как установить первый общий ключ, даже когда получатель офлайн.

X3DH — это начальное «рукопожатие» протокола Signal. После того как первый секрет установлен, эстафету перенимает Double Ratchet — это уже Раздел 16, про шифрование каждого следующего сообщения.

Что сервер знает, а что — нет

Роль сервера здесь — справочник публичных ключей (можно думать о нём как о доске объявлений с prekeys): он хранит и раздаёт всем желающим публичные ключи пользователей. Это просто точка координации.

Чего сервер НЕ знает: приватных частей (они не покидают устройства) и, следовательно, общего секрета. Он видит публичные ключи и шифртекст — но не сам ключ и не текст. Поэтому прочитать переписку он не может.

Одна честная оговорка: серверу всё же приходится доверять в одном — что он выдаст правильные публичные ключи, а не подсунет ключи самозванца, который влезет посередине («человек посередине» из нашего разговора про смысл шифрования). Чтобы закрыть и этот риск, приложения дают пользователям сверить «код безопасности» другим каналом (лично, по звонку). Это и есть та самая остаточная точка доверия.

Связки с другими разделами

• Раздел 10 (мультидевайс): у каждого устройства свои ключи, поэтому X3DH делается отдельно с каждым устройством получателя.
• Раздел 5 (офлайн): prekeys существуют ровно потому, что получатель часто не в сети.

Вопросы интервьюера (с разбором)

«Как Алиса и Боб получают общий секрет, если Боб офлайн?» Образец: «Через заранее загруженные публичные ключи — prekeys. Боб, пока был онлайн, выложил на сервер пачку своих публичных ключей. Алиса берёт их, комбинирует со своими по схеме Диффи — Хеллмана и сразу вычисляет общий секрет, не дожидаясь Боба. Она шифрует первое сообщение и прикладывает свои публичные части; Боб, выйдя в сеть, вычисляет тот же секрет и расшифровывает. Сам секрет по сети не передаётся — только публичные части.»

«Зачем сервер хранит prekeys?» Образец: «Чтобы сделать установку ключа асинхронной. Без prekeys пришлось бы ждать, пока оба окажутся онлайн одновременно, — а в мессенджере так не бывает. Заранее выложенные публичные ключи позволяют установить общий секрет с тем, кого сейчас нет в сети, и отправить ему шифрованное сообщение немедленно.»

«Что именно сервер при этом НЕ знает?» Образец: «Приватные части ключей и сам общий секрет — они никогда не покидают устройства. Сервер видит только публичные ключи и шифртекст, поэтому прочитать сообщения не может. Единственное, чему ему приходится доверять, — что он раздаёт правильные публичные ключи, а не ключи самозванца; этот остаточный риск закрывают сверкой кода безопасности вне мессенджера.»

---

#мессенджер #безопасность #signal-protocol #x3dh #обмен-ключами #prekeys #подготовка-к-интервью