Браузер может выполнять стойкую криптографию; доставляемому в браузер коду всё равно нужно доверять.
Браузер может локально выполнять сквозное шифрование, включая постквантовое установление ключей, без установки нативного приложения для обмена сообщениями. Сложный вопрос не в том, может ли математика работать во вкладке. Вопрос в том, заслуживают ли доставляемое приложение, обработка ключей и путь обновления доверия, необходимого для разговора.
Доступ через веб может быть удобен, когда установка недоступна. Это не делает приложение неуязвимым для цензуры, взломанного хостинга, вредоносных расширений или скомпрометированного устройства.
Криптографические строительные блоки браузера
WebCrypto предоставляет низкоуровневые операции шифрования, выработки ключей, подписи и управления ключами. Распространённые реализации предлагают примитивы вроде AES-GCM и ECDH. Эти операции — строительные блоки, а не полный аутентифицированный протокол обмена сообщениями.
Веб-приложение может добавить проверенную реализацию ML-KEM на JavaScript или WebAssembly там, где необходимый нативный API недоступен. Поддержка браузеров меняется, поэтому разработчикам следует проверять наличие нужных возможностей в конкретных целевых версиях, а не считать, что все браузеры предлагают одинаковые алгоритмы.
Концептуальная гибридная схема выглядит так:
- Создать подходящие ключи с криптографически безопасной случайностью.
- Аутентифицировать ключевой материал собеседника через механизм идентификации протокола.
- Получить классический и постквантовый вклады в общий секрет.
- Объединить их согласно заданной схеме выработки ключей с учётом контекста разговора.
- Использовать выработанные ключи для аутентифицированного шифрования, корректно обрабатывая nonce и состояние.
Это пояснительная схема, а не рецепт реализации. FIPS 203 стандартизирует ML-KEM; он не сертифицирует конкретное браузерное приложение и не определяет каждый шаг протокола чата.
Доставка по HTTPS — часть модели доверия
Сервер обычно поставляет JavaScript и WebAssembly, которые будут обрабатывать открытый текст. Злонамеренно изменённое приложение может прочитать сообщение до шифрования или после расшифрования, даже если его криптографическая библиотека использует надёжные алгоритмы.
HTTPS помогает аутентифицировать доставку и защитить её от сетевого вмешательства. Он не доказывает, что оператор источника, его система развёртывания или зависимости не скомпрометированы. Обычная веб-страница HTTPS не становится автоматически независимо подписанным пакетом приложения.
В рекомендациях W3C по безопасности WebCrypto рассматриваются внедрение скриптов и необходимость защищать целостность приложения. Content Security Policy, тщательное управление зависимостями и другие средства веб-безопасности снижают риски, но ни одно из них не превращает произвольный скрипт того же источника в недоверенного наблюдателя, неспособного затронуть данные приложения.
WebAssembly также разделяет границу безопасности приложения. Его песочница ограничивает доступ к хосту через определённые интерфейсы; она не делает вызывающую страницу заслуживающей доверия. Компиляция C в Wasm не делает исходный язык безопасным в отношении памяти.
Ключи не обязательно существуют только в оперативной памяти
Браузерный мессенджер может сохранять ключи или зашифрованное состояние, чтобы пользователь возвращался к той же идентичности. Он также может предлагать привязку устройств или зашифрованное восстановление. Такое поведение следует документировать, а не предполагать его отсутствие.
Стоит задать следующие вопросы:
- Какие ключи сохраняются и в каком хранилище браузера?
- Что происходит при очистке данных сайта или завершении сеанса приватного просмотра?
- Может ли вредоносный код, работающий в контексте приложения, по-прежнему использовать неизвлекаемый ключ?
- Может ли только что доставленное обновление получить доступ к старому локальному состоянию?
- Восстановление возвращает идентичность, историю сообщений или и то и другое?
Неизвлекаемый ключ WebCrypto ограничивает экспорт через API. Сам по себе он не мешает враждебному коду приложения запрашивать разрешённые операции или собирать открытый текст.
Веб- и нативные клиенты имеют разные компромиссы
| Аспект | Браузерный клиент | Нативный клиент |
|---|---|---|
| Распространение | Источник, хостинг и конвейер веб-обновлений | Магазин приложений или распространение пакетов и конвейер подписи |
| Локальное сохранение | Хранилище браузера и поведение профиля | Хранилище приложения в ОС и жизненный цикл приложения |
| Поверхность воздействия | Скрипты того же источника, расширения и уязвимости браузера | Зависимости приложения и уязвимости ОС/приложения |
| Доступность | Доступный домен и необходимые сетевые службы | Установленному приложению всё равно нужны его сетевые службы |
Ни один столбец не определяет победителя без изучения реализации. Веб-приложение может оставаться доступным после удаления из магазина приложений, но заблокированный домен или отсутствующий сетевой маршрут всё равно могут препятствовать доступу.
Измеряйте производительность вместо обещаний
Согласно FIPS 203, ML-KEM-768 использует ключ инкапсуляции размером 1 184 байта и шифротекст размером 1 088 байт. Эти размеры помогают понять, почему протоколы могут планировать обновления KEM, а не прикреплять новый материал к каждому короткому сообщению. Они не являются измерениями трафика или скорости всего приложения.
Полезный тест указывает браузер, устройство, сборку, метод прогрева, измеряемую операцию и распределение времени выполнения. Учитывайте запуск страницы, загрузку модулей, использование памяти, маломощные устройства и сетевые накладные расходы. Утверждения вроде «менее двух миллисекунд на всех современных телефонах» требуют опубликованных измерений; эта статья их не предоставляет.
Применение к Livara
Обзор безопасности Livara описывает LVR1 и границы его восстановления. Proof Lab демонстрирует отдельные локальные операции P-256, HKDF и AES-GCM; страница явно выводит полную композицию LVR1/LGS1 за рамки этого стенда. Поэтому успешная демонстрация не доказывает безопасность всего поставляемого веб-кода.
Перед конфиденциальным разговором в браузере используйте подлинный поддерживаемый клиент, изучите актуальную модель угроз, защитите профиль браузера и проверьте собеседника через поддерживаемую процедуру проверки ключей. Удобство и полезная криптография могут сосуществовать, если граница доставки через веб остаётся частью оценки.
