Коротко

Аккаунт — пара ключей. Ни номера телефона, ни почты, ни обязательного имени; обнаружение по умолчанию выключено. Запрос оператору связи ничего не даёт: оператора в цепочке нет.

Двунаправленный gRPC: на iOS поверх QUIC с откатом на HTTP/2, на Android поверх HTTP/2 — один долгоживущий стрим, переживающий смену сети без нового хендшейка.

Постквантовость уже в протоколе. ML-KEM-1024 инкапсулируется в Kyber-предключ получателя при установке сессии (PQXDH) и входит в её исходный ключ. Первое сообщение разговора тоже защищено, а без постквантовой части сессия не устанавливается вовсе. Это защищает то, что написано в сообщениях и вложениях. Кто отправил сообщение, тоже скрыто постквантово, звонки — когда оба приложения поддерживают постквантовый DTLS. Пока классические: подписи сервера (сертификаты отправителя, журнал прозрачности ключей), вход устройства и восстановление аккаунта; групп пока нет — все слои перечислены в спецификации протокола.

Отправителя нет в конверте. Защита отправителя* безусловна для обычного трафика. Для доставки у сервера есть непрозрачный идентификатор аккаунта**, размер и время.

  • * Защита отправителя — сообщение уходит без пометки о том, кто его написал. Раскрыть её может только получатель, сервер — нет. В приложении она включена всегда (в настройках безопасности — «стелс»), переключать нечего.
  • ** Непрозрачный идентификатор — это строка, которая ничего о вас не сообщает: набор символов, выданный при создании аккаунта.

Что есть сегодня

Сейчас мессенджер существует как второй канал связи, дополняющий основной. Функционал минимальный — чаты и звонки один на один. Нет групп, каналов, синхронизации между устройствами.

Техническая архитектура

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

Конструкт реализован на основе Signal Protocol (X3DH + Double Ratchet), написанной с нуля на Rust и дополненной постквантовым согласованием ключей (ML-KEM-1024).

Konstruct использует gRPC с Protocol Buffers для эффективного бинарного фрейминга и держит открытым постоянный двунаправленный MessageStream для доставки в реальном времени — без request/response polling. Бэкенд разделён на независимые сервисы (identity, messaging, signaling, media) для изоляции отказов. Боевой путь на iOS — gRPC bidi поверх QUIC с автоматическим фолбэком на HTTP/2; Android работает по HTTP/2.

Стек криптографии

  • X3DH + Double Ratchet (дизайн Signal Protocol): сквозное шифрование с прямой секретностью и post-compromise security (самовосстановление).
  • Постквантовое согласование ключей (PQXDH): при установке сессии инициатор инкапсулирует секрет ML-KEM-1024 (NIST FIPS 203) в Kyber-предключ получателя, и этот секрет входит в исходный ключ сессии вместе с результатами X25519 — так что записанную сессию нельзя восстановить, сломав только X25519. Постквантовая защита действует с самого первого сообщения, и классического пути установки сессии нет. Сверх этого каждая сессия ведёт разреженный ратчет ML-KEM-768 — свежий постквантовый материал подмешивается по ходу разговора (каждые 16 смен направления или раз в 7 дней), а не один раз при установке, и из него выводится свой постквантовый ключ для каждого сообщения.
  • Подписи: гибридные Ed25519 + ML-DSA-65 (Dilithium-3, NIST FIPS 204) на каждом постквантовом предключе — проверяются обе: клиент не примет предключ без обеих подписей. Сам гибридный ключ заверен подписью Ed25519 и закрепляется при первом контакте. Вход устройства, восстановление аккаунта и сертификаты отправителя от сервера пока подписаны только Ed25519.
  • AEAD: ChaCha20-Poly1305 для шифрования сообщений. KDF: HKDF-SHA256 с метками domain-separation для каждой секции протокола. Anti-spam PoW: Argon2id.
  • Сервер не видит содержимого: сообщения хранятся только в виде шифротекста, который сервер не может расшифровать. Токены Privacy Pass могут сопровождать sealed-отправки; server-side enforcement токенов ещё раскатывается.
  • Криптографическая гибкость: протокол несёт версию набора алгоритмов, так что новый набор можно ввести, не меняя формат сообщений. Последние переходы (PQXDH v2, ратчет suite 4) были жёсткими: сессии на старом наборе отклоняются и переоткрываются при следующей отправке. Пока это альфа, мы выбираем такой путь, а не долгую совместимость.

Транспортный уровень

  • Двунаправленный gRPC MessageStream поверх QUIC — боевой путь на iOS (construct-transport). Один долгоживущий поток несёт heartbeat’ы, входящие сообщения и квитанции без TCP-хендшейка на каждое событие, переживает смену сети и автоматически падает на gRPC поверх HTTP/2 + TLS 1.3, когда QUIC режется. Сквозное шифрование лежит выше: транспорт переносит только запечатанный шифротекст, поэтому его смена ничего не меняет в гарантиях.
  • Устойчивость к цензуре: когда прямое TLS-соединение блокируется, клиент уходит через слой обфускации — автоматически и без действий пользователя. Реализация открыта, дизайн публичен. Операционные детали — какие транспорты сейчас в строю, какие точки входа существуют и где они — не публикуются, и ни приложение, ни этот сайт их не показывают.

Что видит сервер

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

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

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

Никакой телеметрии. Даже «обезличенной».

Konstruct не собирает аналитику, метрики использования, поведенческие события, отчёты о крашах и рекламные идентификаторы. Сторонних SDK нет — ни Firebase, ни Crashlytics, ни Sentry, — как нет ATT-запроса и SKAdNetwork. Релизные сборки не пишут никаких логов. Одного мы не контролируем: пока бета идёт в TestFlight, Apple отдаёт нам свои стандартные метрики тестирования — дату установки, версию сборки, число сессий и крашей. Это метрики Apple, не наши, и они закончатся с релизом в App Store. Для маршрутизации сервер хранит только небольшой фиксированный набор метаданных — получатель, время, размер, ваши публичные ключи, на iOS — push-токен, — а защита отправителя убирает из конверта и его самого. Чего это не решает, корреляцию по времени и IP, мы описали в Политике конфиденциальности.

Ключевые возможности

  • Сквозное шифрование по умолчанию — серверы видят только зашифрованные данные.
  • Прямая секретность — прошлые сообщения остаются защищёнными даже при компрометации ключей.
  • Защита от блокировок — включена по умолчанию. Пока прямое соединение работает, используется оно; переключение только при доказанном отказе.
  • Дзен-интерфейс — никакого спама уведомлений, никакого социального шума, только спокойное общение.
  • Постквантовое согласование ключей — ML-KEM-1024 (Kyber-1024) инкапсулируется в Kyber-предключ получателя при установке сессии (PQXDH) и входит в исходный ключ; без него сессия не устанавливается. Дальше каждая сессия продолжает обновлять ключи внутри Double Ratchet на ML-KEM-768, и у каждого сообщения свой постквантовый ключ. Подписи гибридные, Ed25519 + ML-DSA-65 (Dilithium-3): каждый постквантовый предключ подписан обеими, и сессия с предключом без этих подписей не устанавливается.
  • Современный live-транспорт — двунаправленный gRPC MessageStream поверх QUIC (фолбэк на HTTP/2), обход блокировок когда прямой путь закрыт, прямой P2P — в планах, когда оба собеседника онлайн.
  • Открытый код — клиенты, сервер и транспорт под лицензиями с ограниченным копилефтом. Свой сервер — в планах: приложение пока нельзя на него направить.

Принципы проектирования

Две позиции, которыми мы не торгуем:

1. Безопасных бэкдоров не существует. Любое намеренное ослабление шифрования создаёт лазейку, и пройдёт по ней не тот, для кого её оставляли.

2. Приватность по умолчанию. Она должна работать без действий пользователя: это свойство протокола, а не настройка.

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

Спецификация и исходный код

Всё, что описано на этой странице, подробно разобрано в спецификации протокола — whitepaper. Она версионируется рядом с кодом и содержит только то, что можно проверить по эталонной реализации.

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