ДокументацияDocs Home БезопасностьSecurity ПрозрачностьTransparency
KSMP Whisper E2E Pipeline / Ревизия 2026-03-01 / v1.0

Полный путь E2E-пайплайна KSMP Whisper

Настоящий документ описывает сквозной путь E2E-коммуникации: от bootstrap ключей и создания сессии до доставки сообщений, звонкового медиапотока, верификации и ротации ключей.

Оглавление

1. Назначение и границы

  • Документ является технической картой «как проходит E2E-поток» в KSMP Whisper.
  • Документ не заменяет модель угроз и криптоспецификации; он связывает их в единый операционный путь.
  • KSMP Whisper Ultra OOB отвечает за E2E-сообщения и офлайн-создание сессии; WhisperStreamVoice отвечает за E2E-медиапуть звонка.

2. Участники пайплайна

  • Client A / Client B: генерируют, хранят и применяют ключи; шифруют/расшифровывают полезную нагрузку.
  • API/Relay: аутентификация, маршрутизация, очередь, сигнализация; полезная E2E-нагрузка остается шифротекстом.
  • Наблюдатель сети: видит адреса/порты/тайминги/объемы, но не открытый E2E-контент.

3. Сквозная карта E2E-пути

[Bootstrap] A получает prekey/identity bundle B -> проверяет подписи -> выводит стартовый секрет сессии [Message Path] A plaintext -> E2E envelope(ciphertext + auth tag + counters) -> relay/queue -> B verify -> decrypt -> render [Call Path] A/B E2E handshake (pubkeys + callId binding) -> media key -> frame encryption -> wsBinary/callMedia/relay -> decrypt/playback [Lifecycle] SAS/QR/fingerprint verify -> rekey / key-change handling -> session health + UI status

4. Bootstrap ключей и инициализация

  • Клиент генерирует identity key material и хранит его локально (device-bound).
  • Для начала защищенного диалога инициатор получает у сервиса bootstrap/prekey-данные собеседника.
  • Инициатор ДОЛЖЕН проверить идентичность и подписи bundle до выработки рабочего секрета.
  • После успешной проверки создается локальное состояние сессии (root/chain state, счетчики, epoch).

5. Отправка сообщения (Send Path)

  1. Клиент сериализует полезную нагрузку сообщения.
  2. Клиент выводит message key из текущей цепочки ratchet.
  3. Полезная нагрузка шифруется AEAD и упаковывается в E2E envelope.
  4. Envelope отправляется через защищенный транспорт на relay/API.
  5. Relay маршрутизирует шифротекст получателю (онлайн или через очередь).
Сервисный слой может видеть метаданные маршрутизации, но не открытый текст сообщения.

6. Прием сообщения (Receive Path)

  1. Получатель принимает envelope и проверяет валидность служебных полей/версии.
  2. Проверяется целостность и аутентичность AEAD.
  3. Клиент обрабатывает счетчики/ratchet state (включая допустимое out-of-order окно).
  4. Только после успешной верификации выполняется расшифровка и рендеринг текста/вложения.
  5. Невалидные/повторные пакеты отклоняются.

7. Офлайн-доставка и буферизация

  • В режиме недоступности peer сообщение остается E2E envelope и хранится ограниченное время в сервисной очереди.
  • После возвращения клиента B доставляется тот же шифротекст; расшифровка выполняется только на стороне B.
  • Для чувствительных режимов используются более строгие ограничения по TTL и подтверждению сессии.

8. Звонковый E2E-путь (WhisperStreamVoice)

  1. Инициатор отправляет call handshake с E2E-параметрами.
  2. Стороны обмениваются публичными параметрами и выводят общий секрет звонка с привязкой к `callId`.
  3. На базе секрета выводятся рабочие ключи медиапотока.
  4. Каждый аудио/видеофрейм шифруется на клиенте до отправки.
  5. Транспорт выбирается по приоритету: `wsBinaryV1 -> callMediaV1 -> relay`.
Переход в активную передачу выполняется только после согласования transport+E2E контекста.

9. Верификация собеседника

  • Поверх TOFU пользователь может выполнить ручную проверку через SAS/QR/код сверки.
  • При несовпадении кода клиент ДОЛЖЕН маркировать риск MITM и СЛЕДУЕТ ограничивать доверие до повторной проверки.
  • При смене ключа собеседника отображается warning и требуется новая проверка.

10. Rekey, смена ключей и деградация сессии

  • Сессия поддерживает ротацию ключей (policy-driven).
  • На границах epoch клиент ДОЛЖЕН синхронизировать счетчики nonce/counter и состояние ratchet.
  • При критических ошибках проверки сессия переводится в paused/needs-verify, и отправка может блокироваться до восстановления.

11. Что видит сервер и сеть

  • Сервер: идентификаторы маршрутизации, технические метаданные доставки/очереди, время, объем.
  • Сеть/роутер: IP, порт, длительность, объем трафика.
  • Открытый E2E-контент сообщений и звонков НЕ ДОЛЖЕН быть доступен промежуточному транспорту.

12. Нормативные требования

  • Клиент ДОЛЖЕН завершать bootstrap и проверку bundle до отправки первого E2E-пакета.
  • Клиент НЕ ДОЛЖЕН отправлять приватный контент вне E2E envelope в режимах KSMP Whisper.
  • Сервисный слой ДОЛЖЕН рассматривать E2E-пакеты как непрозрачный шифротекст.
  • Клиент ДОЛЖЕН отклонять пакеты с невалидной аутентификацией и недопустимым replay.
  • При изменении ключевых шагов пайплайна публикуется новая ревизия документа.
Предыдущий документ: KSMP Whisper / WhisperStreamVoice · Следующий документ: Транспорт и метаданные.
KSMP Whisper E2E Pipeline / Revision 2026-03-01 / v1.0

Full KSMP Whisper E2E Pipeline

This document describes the end-to-end communication path: bootstrap keys, session creation, message delivery, call media path, peer verification, and key rotation lifecycle.

Contents

1. Purpose and boundaries

  • This is an operational map of how E2E flow works in KSMP Whisper.
  • It complements, not replaces, threat model and crypto specifications.
  • KSMP Whisper Ultra OOB covers E2E messaging and offline session bootstrap; WhisperStreamVoice covers E2E call media path.

2. Pipeline actors

  • Client A / Client B: generate, store, and apply keys; encrypt/decrypt payloads.
  • API/Relay: auth, routing, queue, signaling; message/call payloads remain ciphertext.
  • Network observer: can see addresses, ports, timing, and volume but not plaintext E2E content.

3. End-to-end map

[Bootstrap] A fetches B prekey/identity bundle -> verifies signatures -> derives session bootstrap secret [Message Path] A plaintext -> E2E envelope(ciphertext + auth tag + counters) -> relay/queue -> B verify -> decrypt -> render [Call Path] A/B E2E handshake (pubkeys + callId binding) -> media key -> frame encryption -> wsBinary/callMedia/relay -> decrypt/playback [Lifecycle] SAS/QR/fingerprint verify -> rekey / key-change handling -> session health + UI status

4. Key bootstrap and initialization

  • Client generates device-bound identity key material and stores it locally.
  • To start secure dialog, initiator requests peer bootstrap/prekey data.
  • Initiator MUST validate identity and bundle signatures before deriving operational secret.
  • On success, local session state is created (root/chain state, counters, epoch).

5. Message send path

  1. Client serializes message payload.
  2. Client derives message key from current ratchet chain.
  3. Payload is AEAD-encrypted and wrapped into E2E envelope.
  4. Envelope is sent via protected transport to relay/API.
  5. Relay routes ciphertext to recipient (online or queued).
Service layer can observe routing metadata, not plaintext message content.

6. Message receive path

  1. Recipient parses envelope and validates service fields/version.
  2. AEAD integrity/authenticity is verified.
  3. Client applies counter/ratchet logic (including allowed out-of-order window).
  4. Only valid envelopes are decrypted and rendered.
  5. Invalid/replayed packets are rejected.

7. Offline delivery and buffering

  • When peer is unavailable, message remains encrypted envelope and is held in service queue for bounded TTL.
  • When peer returns online, same ciphertext is delivered and decrypted only on peer device.
  • Higher-sensitivity modes may apply stricter TTL and session-confirmation constraints.

8. Call E2E path (WhisperStreamVoice)

  1. Caller starts call handshake with E2E parameters.
  2. Peers exchange public parameters and derive call secret bound to `callId`.
  3. Media working keys are derived from call secret.
  4. Every audio/video frame is encrypted client-side before transmission.
  5. Transport priority: `wsBinaryV1 -> callMediaV1 -> relay`.
Active media starts only after transport and E2E context are both negotiated.

9. Peer verification

  • On top of TOFU, user may verify via SAS/QR/fingerprint.
  • On mismatch, client MUST surface MITM risk and SHOULD limit trust until re-verification.
  • On peer key change, warning is displayed and re-verification is required.

10. Rekey, key change, session degradation

  • Session supports policy-driven key rotation.
  • At epoch boundaries, client MUST synchronize nonce/counter and ratchet state.
  • On critical validation errors, session transitions to paused/needs-verify and sending may be blocked until recovery.

11. Server/network visibility

  • Server: routing identifiers, technical delivery/queue metadata, timing, volume.
  • Network/router: destination IP, port, duration, traffic volume.
  • Plaintext E2E content of messages/calls SHOULD NOT be available to intermediate transport.

12. Normative requirements

  • Client MUST complete bootstrap and bundle validation before sending first E2E packet.
  • Client MUST NOT send private payload outside E2E envelope in KSMP Whisper modes.
  • Service layer MUST process E2E packets as opaque ciphertext.
  • Client MUST reject invalid authentication and disallowed replay.
  • Any change in core pipeline steps requires new document revision.
Previous: KSMP Whisper / WhisperStreamVoice · Next: Transport & Metadata.