Восстановление криптографической идентичности, повторный вход в учётную запись и восстановление истории чатов — три разные задачи. Согласно документации по безопасности Livara, формат v7 служит для восстановления криптографической идентичности; сам по себе этот формат не восстанавливает историю чатов.
Кроме того, эту архитектуру нельзя описывать как «полное отсутствие облачных резервных копий». В текущем документе сказано, что материалы идентичности шифруются на устройстве, а затем загружаются в виде зашифрованной резервной копии. Важно различать хранение читаемого ключа на сервере и хранение зашифрованной копии, для открытия которой нужен ключ восстановления.
Три двери с разными ключами
| Операция | Цель | Почему этого недостаточно? |
|---|---|---|
| Вход в учётную запись | Подтвердить право доступа к учётной записи сервиса | Не обязательно предоставляет ключ для расшифровки прежних сообщений |
| Восстановление идентичности | Вернуть доступ к материалам криптографической идентичности | Само по себе не доказывает наличие или восстановление всех сообщений |
| Восстановление истории | Вернуть нужные сообщения и вложения | Помимо ключа нужны сами данные и поддерживаемый способ восстановления |
Это разделение предотвращает дорогостоящую ошибку: стирание старого телефона в уверенности, что знания пароля для входа достаточно для возвращения всех разговоров.
Что именно говорится в документации v7?
Страница безопасности Livara объясняет, что ключи согласования и подписи P-256 и начальное значение ML-KEM шифруются на устройстве случайным 256-битным ключом восстановления. В описании формата v7 также аутентифицируются набор алгоритмов, эпоха идентичности и поколение. Это документ производителя, а не сам по себе независимый аудит реализации.
Модель угроз Livara указывает, что фраза восстановления необходима для открытия резервной копии ключей. По этому описанию нельзя угадывать точный алгоритм преобразования фразы в ключ или делать вывод о прямом воссоздании всех ключей. Практические детали нужно сверять с версией приложения и руководством именно для неё.
Почему функция выработки ключей не делает слабую фразу сильной?
Длина выхода функции — не то же самое, что непредсказуемость входа. RFC 5869 прямо говорит, что HKDF концентрирует имеющуюся энтропию, но не увеличивает её. Поэтому нельзя утверждать, что любая произвольная фраза после обработки HKDF автоматически получает полную 256-битную стойкость.
Не сокращайте, не переписывайте и не заменяйте угадываемым предложением фразу, созданную официальным процессом приложения. Не отправляйте её никакому человеку, боту поддержки или неизвестной форме.
Перед заменой или очисткой телефона
- Убедитесь в приложении, что именно сохранено в резервной копии: идентичность, история или и то и другое отдельными способами.
- Храните фразу восстановления в безопасном месте независимо от этого телефона; считайте доступ других людей к ней серьёзным риском.
- Прочитайте руководство по восстановлению для текущей версии. Само сообщение «вход выполнен» не означает полного восстановления.
- Если поддерживается способ проверки восстановления, сначала испытайте его на неконфиденциальных данных, не стирая единственную имеющуюся копию.
- После переноса проверьте нужные разговоры и файлы; лишь затем решайте, можно ли отказаться от старого устройства.
Что делать, если у меня нет фразы восстановления?
Если у вас ещё есть авторизованное устройство, проверяйте только официальные пути, доступные в самом приложении; нельзя предполагать возможность создания новой резервной копии, не проверив версию. Если потеряны и устройство, и фраза, документ Livara не обещает восстановления ключей. Никакой сервис «гарантированной расшифровки» не отменяет этого ограничения.
Начинайте план переноса учётной записи с вопроса «Какие данные, каким ключом и из какой резервной копии будут возвращены?», а не с предположения, что повторный вход равен возвращению всех чатов.
