Як влаштовано шифрування

Месенджер доставляє контейнер

Secure Chat працює окремо від Telegram, пошти та інших способів передавання. На пристрої відправника текст або файл перетворюється на зашифрований контейнер. Вибраним каналом передається цей контейнер, а одержувач розшифровує його локально своїм закритим ключем.

1. Співрозмовники створюють власні профілі й обмінюються публічними картками ключів.
2. Вони незалежно звіряють повні відбитки ключів і підтверджують контакт у програмі.
3. Відправник вибирає свій профіль, одержувача й алгоритм. Secure Chat шифрує вміст і підписує контейнер.
4. Одержувач відкриває контейнер, за потреби вводить пароль гаманця й отримує перевірений результат.

Сам доступ до історії месенджера не дає закритого ключа Secure Chat. Додатковий рівень захисту корисний саме для вмісту, який ви заздалегідь зашифрували. Він не приховує факту спілкування, учасників, часу передавання чи мережевих адрес і не захищає пристрій, на якому вже діє шкідлива програма.

Дві пари ключів у кожному профілі

Публічна картка .scpub містить ім'я, обидва публічні ключі, відбиток і версію формату. Закритих ключів у ній немає. Формат картки — читабельний JSON; двійкові поля записуються в Base64.

Format: SecureChat.PublicKey
Version: 1
Name
EncryptionPublicKey
SigningPublicKey
Fingerprint

Як перевіряється співрозмовник

Відбиток об'єднує обидва публічні ключі в один хеш SHA-256: 64 шістнадцяткових символи. Перед надсиланням його потрібно повністю звірити особисто або іншим довіреним каналом. Ім'я в імпортованій картці не є доказом особи.

SHA256(
  UTF8("SecureChat.Identity.v1\0")
  || int32BE(length(RSA_SPKI)) || RSA_SPKI
  || int32BE(length(ECDSA_SPKI)) || ECDSA_SPKI
)

Імпортований контакт завжди отримує статус неперевіреного. Програма дозволяє шифрування цьому контакту після підтвердження звіряння. Власні профілі можна вибирати одержувачами для перевірки роботи програми.

Коректний цифровий підпис підтверджує відповідність контейнера ключу підпису. Зв'язок цього ключа з конкретною людиною встановлюється звіреним відбитком. Для невідомого чи незвіреного ключа програма окремо показує, що особу відправника не підтверджено.

Окремий випадковий ключ для кожного контейнера

Кожне нове повідомлення й кожен файл отримують новий випадковий 256-бітний ключ через RandomNumberGenerator.GetBytes . Користувач вибирає один із двох режимів автентифікованого шифрування — AEAD:

ChaCha20-Poly1305 пропонується лише за підтримки операційною системою. Вибраний алгоритм входить до автентифікованого заголовка; автоматичного перемикання на слабший варіант немає.

Випадковий ключ вмісту шифрується публічним RSA-ключем одержувача. Його окрема копія шифрується публічним RSA-ключем відправника, тому відправник теж може відкрити своє вихідне повідомлення. При надсиланні собі створюється один такий слот.

AEAD перевіряє цілісність вмісту та пов'язаних даних. Підпис ECDSA-P256/SHA-256 додатково пов'язує контейнер із ключем відправника. Невдала перевірка перериває розшифрування.

Гаманець під паролем

Профілі із закритими ключами, контакти, захищені налаштування та історія містяться в одному файлі Data/wallet.scvault поруч із програмою. Для шифрування гаманця використовується AES-256-GCM.

Пароль і окремий перевірочний хеш пароля не зберігаються. PBKDF2 сповільнює перебір, але стійкість захисту й далі залежить від самого пароля. Для довгої унікальної парольної фрази бажано використовувати випадкові слова або менеджер паролів.

Заголовок завдовжки 64 байти теж автентифікується. Після нього записуються шифротекст і тег:

"SCVAULT1"[8]
|| version:int32LE
|| iterations:int32LE
|| salt[32]
|| nonce[12]
|| ciphertext_length:int32LE
|| ciphertext
|| tag[16]

Формат версії 1 приймає лише задані параметри KDF, обмежений розмір і точну довжину файлу. Запис виконується через повністю підготовлену зашифровану копію та заміну файлу. Паралельний запис і збереження поверх виявлених зовнішніх змін відхиляються. Службовий .lock не містить ключів.

Що записано у відкритому заголовку

Контейнер повідомлення або файлу починається з чотирьох байтів типу, довжини JSON-заголовка та самого заголовка. Розмір JSON обмежено 16 384 байтами.

magic[4] || header_length:int32LE || header_json[header_length]

Ці метадані не зашифровані. Видимі алгоритм, розмір, назва файлу, публічні ключі та відбитки. Постійні ключі дозволяють пов'язувати контейнери одного відправника. Якщо назва файлу чутлива, перейменуйте його перед шифруванням.

Відкритий заголовок захищено від непомітної підміни: підпис і AEAD використовують його вихідні байти, а не повторно зібраний JSON. В описі нижче || означає з'єднання байтів. Цілі числа записуються little-endian; винятки з big-endian явно позначені.

Текст: контейнер SC1 і вкладення .scmsg

Вихідний текст обмежено 1 МіБ у строгому кодуванні UTF-8. Двійковий контейнер має тип SCT1 :

"SCT1"
|| header_length:int32LE || header_json
|| ciphertext_length:int32LE || ciphertext
|| tag[16] || signature[64]

Як додаткові автентифіковані дані (AAD) використовується весь префікс: тип, довжина та JSON заголовка. Підпис ECDSA-P256 обчислюється над SHA-256 усіх попередніх байтів. Формат підпису — IeeeP1363FixedFieldConcatenation : r || s , по 32 байти.

Для передавання двійковий контейнер перетворюється в Base64url без символів заповнення = :

SC1:<base64url(binary_container)>
securechat://message/<base64url(binary_container)>

Перш ніж розкрити текст, програма перевіряє структуру, точну довжину та підпис, потім розшифровує RSA-обгортку й перевіряє AEAD. Неприпустимі символи, переноси всередині конверта, додаткові URI-параметри й пошкоджені дані відхиляються.

Передавання через Telegram

Кнопка «Файл для чату» копіює зашифрований .scmsg у файловий буфер Windows. Вставте його в чат через Ctrl + V і надішліть вкладення. Одержувач завантажує файл і відкриває його в Secure Chat. Заблокована програма спочатку запитає пароль.

Звичайний конверт SC1:… також можна копіювати й вставляти вручну. Windows-посилання securechat://… обмежене 8000 символами та стає клікабельним не в усіх клієнтах. Telegram Desktop не перетворює цю довільну схему на звичайне автопосилання; для нього призначене вкладення .scmsg . Старі .sct відкриваються явно всередині програми.

Файли: блоки, підпис і два проходи перевірки

Зашифрований файл отримує розширення .scx і тип SCF1 . Межа вихідного файлу у форматі — 1 ТіБ. Обробка потокова: файл повністю не завантажується в пам'ять, вміст розділено на блоки по 1 МіБ.

"SCF1" || header_length:int32LE || header_json
|| (chunk_length:int32LE || ciphertext[chunk_length] || tag[16])*
|| 0:int32LE || terminal_tag[16]
|| signature[64]

Для кожного блока отримується власний 12-байтовий nonce. Він складається з випадкового чотирибайтового префікса контейнера та восьмибайтового індексу блока:

nonce = Nonce[4] || uint64BE(chunk_index)
AAD   = SHA256(full_prefix)[32]
        || uint64BE(chunk_index)
        || int32LE(chunk_length)

Індекс починається з нуля. Завершальний порожній блок отримує наступний індекс і власний тег. Навіть порожній файл має заголовок, завершальний блок, тег і підпис. Ключ вмісту генерується заново для кожного нового файлу.

До підпису входять усі байти від SCF1 до завершального AEAD-тега включно. Перевіряються порядок і розмір блоків, точна довжина контейнера та кінець файлу. Перестановка, дублювання, видалення блоків, обрізання або дописування спричиняють відмову.

Що відбувається при розшифруванні

1. Перевіряються обмежений заголовок, довжина файлу та наявність відповідного закритого ключа.
2. Перший прохід читає контейнер і перевіряє повний підпис. Відкритий тимчасовий файл ще не створюється.
3. Другий прохід перевіряє AEAD кожного блока, записує розшифровані дані в тимчасовий файл і повторно перевіряє підсумковий підпис.
4. Після успішного завершення результат перейменовується у вибраний користувачем новий файл. Наявний файл не перезаписується.

Рядок стану показує загальний відсоток: перевірку підпису, розшифрування та збереження. 100% означає успішне збереження результату. Кнопка скасування доступна під час обробки; при штатній помилці чи скасуванні тимчасовий файл видаляється.

Вихідний файл зберігається. Розшифрований результат не запускається автоматично. Збій живлення, примусове завершення процесу чи зовнішній дескриптор, що заважає видаленню, можуть залишити тимчасовий відкритий файл. Захист вихідної папки й диска залишається важливою частиною роботи із секретами.

Локальне зберігання, історія та блокування

Історія містить метадані операцій і зашифровані текстові конверти. Відкритий текст і вміст файлів до неї не записуються. Зберігаються останні 100 записів із загальним розміром конвертів близько 8 МіБ; старі записи видаляються автоматично. Історію можна вимкнути або очистити.

Гаманець блокується через Ctrl + L , при згортанні, блокуванні чи відключенні сеансу Windows, переході в сон і за бездіяльності. Інтервал бездіяльності вибирається від 1 до 15 хвилин, типово — 5 хвилин. Поточна файлова операція скасовується перед звільненням ключів.

При блокуванні очищуються поля та посилання на записи, а масиви закритих ключів і похідного ключа, які належать програмі, обнуляються. Повне видалення всіх копій із пам'яті не гарантується: керовані рядки, буфер обміну, дампи й файл підкачки можуть зберігати залишки даних.

Два різні режими буфера обміну

«Копіювати текст» позначає власний запис програми та очищує його через 30 секунд або при блокуванні, якщо запис ще належить Secure Chat. Новіший запис іншої програми не стирається. Звичайне копіювання системною командою Ctrl + C цим таймером не керується.

«Файл для чату» розміщує у Windows FileDrop шлях до готового .scmsg , що містить лише шифротекст. Ця копія залишається доступною після блокування й закриття гаманця, щоб месенджер встиг її прочитати. Кожне копіювання створює окреме вкладення.

Копії, старші за 24 години, очищуються при наступному запуску чи копіюванні. Одночасно зберігається до 128 тимчасових вкладень; при досягненні межі можна явно зберегти повідомлення у вибрану папку. Заборони історії та хмарного буфера передаються як підказки Windows; сторонні менеджери буфера можуть їх ігнорувати.

Резервні копії, перенесення та оновлення

Резервна копія — повний зашифрований гаманець. Для відкриття потрібен пароль, який діяв на час створення. Після додавання нових ключів оновіть резервну копію. Відновлення доступу без пароля й закритих ключів не передбачено.

Зміна пароля, видалення профілю чи очищення історії змінюють поточний гаманець. Старі резервні копії зберігають попередній пароль, ключі та історію. Видалення запису теж не гарантує фізичного стирання даних із SSD, зі знімків і журналюваної файлової системи.

Для оновлення до 0.1.6 закрийте Secure Chat і замініть SecureChat.exe у попередній папці. Збережіть усю папку Data. Формати гаманця та контейнерів залишаються версії 1, міграція не потрібна. Для майбутніх випусків зі зміною формату порядок міграції буде описано окремо.

При перенесенні в іншу папку переносьте EXE разом із Data і потрібними зовнішніми перекладами Languages . Потім увімкніть обробку .scmsg , .scx і посилань у налаштуваннях знову: реєстрація Windows зберігає абсолютний шлях. Однофайловий EXE може видобувати нативні бібліотеки .NET у системний кеш користувача.

Які мережеві звернення є в програми

Для шифрування та розшифрування сервер не потрібен. У Secure Chat немає транспорту повідомлень, облікового запису для обміну ключами чи сервісу скидання пароля. Доставку контейнерів виконує вибраний вами месенджер, пошта або інший канал.

Після натискання «Перевірити оновлення» програма отримує невеликий JSON з https://itmsft.com/securechat/update/latest.json . Перевірку під час запуску можна ввімкнути окремо; типово вона вимкнена. Передаються звичайні мережеві відомості HTTPS-запиту й загальний User-Agent із версією програми. Пароль, ключі, профілі, історія та вміст файлів до запиту не включаються.

Клієнт обмежує розмір відповіді 64 КіБ і час читання 10 секундами, перевіряє версію та наявність пакета для своєї архітектури. Помилка сервера, мережі чи формату показує неможливість перевірки й не оголошує встановлену версію актуальною.

Кнопка завантаження відкриває дозволену HTTPS-адресу пакета на itmsft.com у звичайному браузері. Програма не виконує автоматичного встановлення й не запускає завантажений файл. Формат поля SHA-256 перевіряється, але байти завантаженого браузером ZIP програма не перевіряє. У версії 0.1.6 цифрового підпису видавця в EXE немає.

Межі, які важливо враховувати

• Безпека пристрою. Шкідлива програма, кейлогер, читання пам'яті, підміна EXE чи віддалений доступ можуть розкрити текст до шифрування та після розшифрування.
• Метадані. Видимі відкритий заголовок контейнера та мережеві відомості каналу передавання. Це не засіб анонімності.
• Статичні ключі. Forward secrecy не реалізовано: викрадений закритий ключ дозволяє читати раніше перехоплені контейнери для цього ключа.
• Відновлення секретності. Double Ratchet і post-compromise security відсутні. Це власний формат, а не реалізація протоколу Signal.
• Повтори та відкат. Валідний контейнер можна надіслати повторно. Коректна стара копія гаманця не захищена від відкату: цілісність не доводить актуальності.
• Пароль. Мінімальна довжина й затримка в інтерфейсі не зупиняють офлайн-перебору викраденого гаманця. Основні заходи — сильний пароль і KDF.
• Видалення даних. Повне стирання з RAM, підкачки, хмарного буфера та накопичувача не гарантується.
• Криптографічні властивості. Схема не є постквантовою. Підпис можуть перевірити треті особи, які отримали контейнер; криптографічна заперечуваність не надається.
• Статус перевірки. Стандартні примітиви й автоматичні тести не замінюють незалежного аудиту протоколу та реалізації.

Secure Chat додає окремий контроль над вибраним вмістом. Для використання з особливо чутливими даними потрібні оцінка вашої моделі загроз, захищений пристрій і незалежна експертна перевірка реалізації.

Запросити доступ до вихідного коду →