Стандартизований компонент — відправна точка для перевірки, а не сертифікат для всього месенджера.
ML-KEM-768 допомагає двом сторонам встановити спільний секрет, який потім можна використовувати для захисту повідомлень. Це один компонент системи обміну повідомленнями, а не повний протокол чату, шифр повідомлень чи сертифікат безпеки застосунку.
NIST опублікував FIPS 203 13 серпня 2024 року, стандартизувавши ML-KEM та його набори параметрів 512, 768 і 1024. Їхня безпека спирається на задачі на ґратках, які вважають стійкими до квантових атак. «Вважають стійкими» — це припущення безпеки, підтримане аналізом, а не обіцянка неможливості майбутніх слабкостей. NIST FIPS 203.
Місце KEM у зашифрованому чаті
Корисний спосіб читати заяву про шифрування — простежити за ключовим матеріалом:
- Автентифікувати потрібного співрозмовника. Обмін ключами із самозванцем усе одно є обміном ключами не з тією людиною.
- Встановити спільний секретний матеріал. KEM додає секрет через інкапсуляцію та декапсуляцію.
- Вивести ключі для їхніх конкретних цілей. Функція виведення ключів розділяє матеріал, який використовують різні частини протоколу.
- Шифрувати й автентифікувати повідомлення. Схема автентифікованого шифрування захищає вміст і виявляє несанкціоновані зміни.
- Керувати сеансом із часом. Ротація та видалення ключів, зміни пристроїв і відновлення визначають, що може розкрити пізніша компрометація.
Ці кроки пояснюють, чому стандарт для другого кроку не може підтвердити безпеку всього застосунку. Поширені запитання NIST про постквантову криптографію надають контекст для впровадження нових стандартів.
Навіщо поєднувати ML-KEM із класичним узгодженням ключів?
Гібридна схема використовує постквантовий компонент поряд із класичним, наприклад Діффі — Геллманом на еліптичних кривих. Її очікувана перевага — не залежати виключно від одного з наборів припущень у перехідний період.
Твердження про безпеку стосується повного механізму поєднання та протоколу, а не просто переліку двох алгоритмів. Перевіряльникам потрібно знати, які вхідні дані автентифікуються, як їх кодують і поєднують, який контекст прив’язується до виведення ключів і що відбувається, коли компонент відмовляє. Конкатенація секретів без визначеної конструкції — не аргумент безпеки.
Для користувачів практичне запитання — не «Чи написано в налаштуваннях “квантово-безпечно”?», а «Які розмови та версії насправді використовують цю конструкцію і які докази підтримують це твердження?»
Що документує Livara
Документація з безпеки Livara описує сеанси особистих чатів LVR1 із класичним матеріалом P-256 і ML-KEM-768 та AES-256-GCM для вмісту. Вона описує приватні групи LGS1 як ланцюжки відправників, що поширюються через попарні сеанси LVR1. Це різні рівні: звичайне групове повідомлення не обов’язково є новим обміном ML-KEM для кожного одержувача.
Читайте цю документацію як опис розробника. Називання стандартизованих примітивів не доводить, що власна композиція Livara пройшла незалежний аудит або що кожна встановлена збірка реалізує її правильно. Proof Lab явно обмежує свою браузерну демонстрацію: вона не виконує повні храповики LVR1/LGS1 і не є аудитом протоколу.
Чого не охоплює постквантовий захист
| Запитання | Чому самого ML-KEM недостатньо для відповіді |
|---|---|
| Чи може одержувач скопіювати моє повідомлення? | Одержувач отримує читабельний вміст. |
| Чи немає на моєму пристрої шпигунського ПЗ? | Цілісність кінцевої точки — окреме припущення довіри. |
| Чи захищено резервні копії? | Ключі резервного копіювання та правила відновлення потребують власної схеми. |
| Чи безпечні зміни складу групи? | Мають значення правила автентифікації, членства та зміни ключів. |
| Чи зберігає сервіс метадані? | Шифрування вмісту автоматично не приховує маршрутизацію чи час. |
| Чи захищено дзвінок так само, як текстовий чат? | Сигналізація дзвінка та медіадані можуть використовувати різні протоколи. |
Модель загроз Livara також розрізняє приватні розмови та публічні канали й визнає ризик розкриття на рівні пристрою. Не поширюйте твердження про особисті чати на всі області продукту.
Пам’ятка покупцеві «месенджера з FIPS 203»
Запросіть точний набір параметрів і версію протоколу; опис автентифікації співрозмовника та поєднання ключів; підтримувані версії клієнтів; поведінку з несумісними клієнтами; а також тести чи результати перевірок, прив’язані до реалізації, що постачається. Якщо постачальник заявляє про валідацію FIPS, попросіть відповідний запис про валідацію та її область охоплення. Використання алгоритму, описаного в публікації FIPS, саме по собі не є доказом валідації продукту чи модуля.
Не робіть висновків про час роботи від батареї, пропускну здатність чи швидкість відгуку застосунку з назви параметрів. Для цього потрібні вимірювання із задокументованими пристроєм, збіркою та навантаженням.
Корисна зміна для обміну повідомленнями — новий інструмент довгострокової конфіденційності. Його цінність залежить від інтеграції, реалізації та експлуатаційних меж, а не від заміни одного маркетингового ярлика іншим.
