Попередні ключі дозволяють одержувачу бути офлайн під час встановлення сеансу. Вони не усувають потреби в каналі доставки й ретельному керуванні життєвим циклом закритих ключів.
Одержувач офлайн може отримати зашифроване повідомлення пізніше, оскільки його пристрій заздалегідь опублікував відкритий ключовий матеріал. Відправнику все одно потрібен доступний сервіс доставки; «асинхронне шифрування» не означає, що повідомлення долають відсутність мережевого з’єднання або миттєво з’являються на відключеному телефоні.
Постквантові схеми розширюють цю ідею механізмом інкапсуляції ключів. Важливі питання — як встановлюється початковий секрет, як виводяться з обігу старі закриті ключі та як наступні повідомлення оновлюють захист.
Попередні ключі розв’язують проблему розбіжності в часі
Уявіть, що Мая не в мережі, коли Сем починає нову розмову. Пристрій Маї раніше завантажив відкриті попередні ключі. Сем може отримати цей матеріал, виконати свою сторону узгодження ключів і надіслати зашифроване перше повідомлення. Мая обробить його після підключення, використовуючи закриті ключі, що зберігаються на її пристрої.
Отже, сервер надає відкриту інформацію та ставить зашифровані дані в чергу; йому не обов’язково володіти отриманим секретом повідомлень. Специфікація X3DH від Signal — першоджерело опису цієї асинхронної схеми. Підписаний попередній ключ та одноразовий попередній ключ мають різні строки життя й ролі; «попередній ключ» не означає секретний пароль, завантажений на сервер.
Для вже встановленої розмови застосунок може використовувати наявний стан сеансу замість повторення початкового налаштування для кожного повідомлення. Початок сеансу та просування його ключів повідомлень — окремі операції.
Що додає постквантовий KEM
Механізм інкапсуляції ключів має три основні операції: генерування ключів, інкапсуляцію з використанням відкритого ключа та декапсуляцію за допомогою відповідного закритого ключа. Інкапсуляція створює і спільний секрет, і шифротекст. Шифротекст можна доставити пізніше; сам секрет не передається відкритим текстом.
NIST FIPS 203 стандартизує ML-KEM. Для ML-KEM-768 відкритий ключ інкапсуляції займає 1184 байти, шифротекст — 1088 байтів, а спільний секрет — 32 байти. Це розміри на рівні алгоритму, а не розмір цілого пакета повідомлення. Підписи, класичні ключі, ідентифікатори та транспортне обрамлення додають накладні витрати; кешований відкритий ключ може не супроводжувати кожне повідомлення.
У гібридній конструкції протокол поєднує класичний і постквантовий секретний матеріал відповідно до визначеної схеми вироблення ключів. Просте поєднання назв алгоритмів не встановлює безпеки їхньої композиції. Прив’язка ідентичності, валідація, розділення доменів та обробка збоїв потребують специфікації й перевірки.
Приклад: PQXDH, а не універсальний шаблон
Специфікація PQXDH від Signal описує підписані одноразові постквантові попередні ключі та підписаний резервний ключ на крайній випадок. Відправник перевіряє надані підписи, виконує узгодження ключів і включає шифротекст KEM та ідентифікатори ключів до початкового зашифрованого повідомлення. Одержувач пізніше виводить той самий секрет і обробляє повідомлення.
Резервний ключ підтримує встановлення сеансу, коли одноразові ключі KEM недоступні, але аналіз наслідків компрометації відрізняється. Видалення та ротація закритих ключів впливають на захист попередніх сеансів. Специфікація також розрізняє постквантову пряму секретність і автентифікацію проти активного квантового нападника. Ці подробиці не слід замінювати твердженням «резервний варіант не має ціни для безпеки».
PQXDH — одна конкретно описана конструкція. Її точні криві, підписи та параметри не слід переносити в опис іншого продукту, якщо цей продукт їх не документує.
Храповик — не те саме, що пул попередніх ключів
Попередні ключі підтримують встановлення сеансу. Храповиковий протокол змінює секрети під час розмови. Специфікація Double Ratchet пояснює еволюцію ключів повідомлень і новіші постквантові храповикові конструкції, зокрема схеми, які не передають повний постквантовий обмін із кожним повідомленням застосунку.
Пряма секретність стосується попередніх повідомлень після пізнішої компрометації ключа. Посткомпрометаційна безпека стосується відновлення захисту майбутнього спілкування після того, як нападник утратив доступ і було включено свіжий секретний матеріал. Жодна з них не означає, що шкідливе ПЗ може нескінченно залишатися на телефоні, а криптографія якимось чином приховує від нього відкритий текст цього телефона.
Видалення відкритого попереднього ключа із сервера запобігає його звичайному повторному використанню; це не рівнозначно видаленню відповідного закритого ключа з кінцевого пристрою. Корисний аудит перевіряє і правила життєвого циклу, і поведінку із затриманими повідомленнями.
Що документує Livara — і що ще потребує доказів
Сторінка безпеки Livara описує гібридне встановлення сеансу з одноразовими ключами за їх наявності, звичайне просування ланцюжків повідомлень і періодичні епохи ML-KEM. Це відрізняється від старого твердження, нібито кожне повідомлення виконує повний новий обмін ML-KEM. Це положення документації продукту, а не незалежна перевірка реалізації.
Не виводьте з цих тверджень конкретної резервної політики на випадок вичерпання ключів, інтервалу поповнення чи величини мережевої затримки. Ці питання потребують документації протоколу для конкретної версії або результатів вимірювань. Proof Lab також не є повним тестом асинхронного встановлення сеансу, вичерпання ключів або відновлення обробки затриманих повідомлень.
Як оцінювати заяви про обмін повідомленнями офлайн
Попросіть постачальника або перевіряльника надати свідчення щодо таких випадків:
| Тестовий випадок | Що спостерігати |
|---|---|
| Перше повідомлення відключеному співрозмовнику | Який відкритий ключовий матеріал використано й коли одержувач насправді отримує повідомлення |
| Вичерпані одноразові попередні ключі | Чи зупиняється встановлення сеансу, чи застосовується документований резервний варіант і який його заявлений компроміс щодо безпеки |
| Одержувач перевстановлює застосунок або змінює ідентичність | Чи залишаються старі повідомлення в черзі придатними до розшифрування та чи видимі зміни ключів |
| Затримані повідомлення або повідомлення зі зміненим порядком | Межі зберігання, обробка пропущених ключів і зрозумілі помилки |
| Повернення після тривалої відсутності | Безпечне оновлення ключів, обмежений обсяг обробки та точний статус доставки |
| Порівняння продуктивності | Пристрій, версія застосунку, мережа, розмір корисного навантаження та окремі вимірювання холодного старту й установленого сеансу |
Використовуйте тестові облікові записи й повідомлення без чутливих даних. Успішний тест доставки демонструє цей сценарій, а не кожну криптографічну властивість. І навпаки, невдала доставка може бути проблемою мережі чи життєвого циклу, а не зламом шифру.
Поширені запитання
Чи може одержувач бути офлайн, поки я надсилаю повідомлення?
Так, якщо застосунок має необхідний відкритий матеріал та інфраструктуру доставки й зберігання. Одержувач не зможе прочитати повідомлення в черзі, доки його пристрій не зможе отримати й обробити його.
Чи завжди більші ключі KEM помітно сповільнюють чат?
Із самого розміру ключа не випливає універсальне твердження про час. Мають значення частота встановлення сеансу, пакетна обробка, кешування, реалізація та мережеві умови. Публікуйте результати тестування замість обіцянок нульових накладних витрат.
Чи доводить підписаний попередній ключ особу людини за обліковим записом?
Він автентифікує матеріал відносно ідентичності підписанта. Як ця ідентичність пов’язана з людиною, з якою ви хочете зв’язатися, — окреме питання довіри й перевірки.
Чи працює постквантове шифрування взагалі без з’єднання?
Деякі локальні обчислення можна виконувати офлайн. Доставка повідомлень усе одно потребує каналу зв’язку; криптографія його не надає.
