Криптографічна гнучкість — це здатність перевести протокол з одного криптографічного набору на інший, зберігаючи чіткі зобов’язання щодо безпеки. В обміні повідомленнями це означає більше, ніж додавання назви нового алгоритму. Старі клієнти, одержувачі поза мережею, збережені повідомлення та пов’язані пристрої мають поводитися передбачувано під час переходу.
У RFC 7696 IETF гнучкість алгоритмів описано як завдання міграції, що охоплює ідентифікатори, реалізації та експлуатаційні зміни. Номер версії допомагає визначити, що використовується; сам собою він не робить міграцію безпечною.
Три версії, які легко сплутати
Месенджер може мати версію застосунку, версію протоколу передавання та ідентифікатор криптографічного набору. Вони відповідають на різні запитання:
| Ідентифікатор | Що він повідомляє перевіряльнику | Чого він не доводить |
|---|---|---|
| Випуск застосунку | Яку збірку програми встановлено | Що кожна розмова використовує найновіший протокол |
| Версія протоколу | Який формат повідомлень і правила стану застосовуються | Що реалізація правильно дотримується цих правил |
| Ідентифікатор алгоритму або набору | Які криптографічні компоненти обрано | Що узгодження неможливо примусово понизити |
Примітки до випуску мають явно пояснювати цей зв’язок. «Випущено нове шифрування» — неоднозначне формулювання, якщо його використовують лише новостворені розмови або якщо старіший пов’язаний клієнт спричиняє повернення до попереднього режиму.
Що має визначати безпечна міграція
Почніть із конкретного сценарію: Аліса оновлюється сьогодні, а Боб залишається поза мережею зі старим телефоном. Аліса надсилає повідомлення, а згодом додає другий пристрій. Що кожен пристрій має приймати, зберігати та відображати?
Проєкт, придатний для перевірки, відповідає щонайменше на такі запитання:
- Як кожна сторона дізнається, які версії підтримує інша?
- Чи автентифікується обрана версія як частина сеансу?
- Що відбувається, коли спільної прийнятної версії немає?
- Чи може зловмисний ретранслятор видалити відомості про можливість і спричинити слабший режим?
- Чи залишаються старі повідомлення читабельними та які старі ключі ще потрібні?
- Чи відновлює резервна копія застарілий стан протоколу?
- Коли застарілі алгоритми буде вимкнено, а не просто оголошено небажаними?
Помітна відмова часто безпечніша за непомітний перехід у режим, якого користувач не мав наміру використовувати. Проте точну поведінку під час відмови й відновлення слід документувати, щоб люди не обходили проблему переходом на незахищений канал.
Практична матриця випробувань оновлення
Оновлення безпеки потребує більшого, ніж успішний чат між двома свіжими встановленнями. Перевірте ці випадки з нечутливими даними:
| Випробування | Які свідчення записати |
|---|---|
| Новий клієнт спілкується зі старим | Обраний протокол або чіткий результат несумісності |
| Одержувач поза мережею під час оновлення | Поведінка доставки та розшифрування після підключення |
| Повертається старий пов’язаний пристрій | Чи може він читати, надсилати або нав’язати неочікуваний режим |
| До групи додають несумісного учасника | Явна політика групи та видимий користувачу стан |
| Резервну копію відновлюють після припинення підтримки | Чи відхиляється непідтримуваний стан, чи мігрує |
| Метадані версії підроблено | Відмова автентифікації замість непомітного пониження |
Це критерії оцінювання, а не твердження, що названий продукт пройшов випробування. Зберігайте ідентифікатори збірок і спостережувані результати, щоб згодом відрізнити регресію від зміни документації.
Як розуміти назви протоколів Livara
У своїй документації з безпеки Livara називає LVR1 протоколом особистих чатів, а LGS1 — приватних груп. Ці назви розмежовують обов’язки; їх не слід вважати доказом незалежної стандартизації чи аудиту. Сторінка також розглядає поведінку клієнтів або груп, які не можуть виконати передумови зашифрованого режиму.
Наступними корисними свідченнями були б версійована специфікація, тестові вектори, правила сумісності та результати перевірки, прив’язані до конкретного випуску. Proof Lab прямо визначає вужчі межі своєї демонстрації. Випробування примітивів у браузері — не те саме, що тестування кожного шляху міграції в застосунку.
Що робити користувачам під час оновлення шифрування
Оновлюйте підтримувані клієнти, читайте повідомлення безпеки про сумісність пристроїв і звертайте увагу на змінені індикатори ідентичності або стану шифрування. Не вважайте, що новий значок застосунку означає новий захист усіх старих груп і резервних копій. Якщо продукт не може пояснити, для яких даних змінився захист, запитайте про це перед передаванням чутливих матеріалів.
Хороша криптографічна гнучкість робить зміни доступними для перевірки. Вона визначає, що змінилося, як сторони це узгоджують, що може піти не так і коли старий механізм перестає прийматися.
