Коротко

Обліковий запис — пара ключів. Ні номера телефону, ні пошти, ні обов’язкового імені; виявлення за замовчуванням вимкнене. Запит до оператора зв’язку нічого не дає: оператора в ланцюжку немає.

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

Постквантовість уже в протоколі. ML-KEM-1024 інкапсулюється в Kyber-передключ отримувача під час встановлення сесії (PQXDH) і входить до її початкового ключа. Перше повідомлення розмови теж захищене, а без постквантової частини сесія не встановлюється взагалі. Це захищає те, що написано в повідомленнях і вкладеннях. Хто надіслав повідомлення, теж приховано постквантово, дзвінки — коли обидва застосунки підтримують постквантовий DTLS. Поки класичні: підписи сервера (сертифікати відправника, журнал прозорості ключів), вхід пристрою та відновлення облікового запису; груп поки немає — усі шари перелічено в специфікації протоколу.

Відправника в конверті немає. Захист відправника* безумовний для звичайного трафіку. Для доставки сервер має непрозорий ідентифікатор облікового запису**, розмір і час.

  • * Захист відправника (sealed sender) — повідомлення йде без позначки про те, хто його написав. Розкрити її може лише отримувач, сервер — ні. У застосунку вона завжди ввімкнена (у налаштуваннях безпеки — «стелс», Security ▸ stealth), перемикати нічого.
  • ** Непрозорий ідентифікатор — це рядок, який нічого про вас не повідомляє: набір символів, виданий під час створення облікового запису.

Що є сьогодні

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

Технічна архітектура

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

Konstruct реалізований на основі 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-handshake на кожну подію, переживає зміну мережі й автоматично переходить на gRPC поверх HTTP/2 + TLS 1.3, коли QUIC ріжуть. Наскрізне шифрування лежить вище: транспорт переносить лише запечатаний шифротекст, тому його зміна нічого не змінює в гарантіях.
  • Стійкість до цензури: коли пряме TLS-з’єднання блокується, клієнт іде через шар обфускації — автоматично й без дій користувача. Реалізація відкрита, дизайн публічний. Операційні деталі — які транспорти зараз у строю, які точки входу існують і де вони — не публікуються, і ні застосунок, ні цей сайт їх не показують.

Що бачить сервер

Будь-яка централізована платформа виходить з одного припущення: «ви» — це рядок у її базі даних. Номер телефону, профіль, граф контактів, який їй належить і який вона може передати. Konstruct починає з меншого. Сервер зберігає ідентифікатор облікового запису, ваші публічні ключі та push-токен. Про саме повідомлення він бачить лише непрозорий ідентифікатор отримувача, час доставки й розмір; захист відправника (sealed sender) прибирає ідентифікатор відправника, тож розкрити, хто написав, може лише отримувач. Рівно стільки потрібно для маршрутизації шифротексту.

Без телефонної книги немає «холодних» повідомлень: розмова починається з 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: зовнішнього аудиту не було. Усе, що вище, — це наше власне прочитання нашого ж коду. Ніхто поза проєктом його не перевіряв, і поки це так, вважайте ці властивості заявами, які ми готові відстоювати, а не результатами перевірки.