Кратко

  • RFC 9807 позволяет регистрировать и аутентифицировать клиента, не раскрывая пароль серверу; однако утечка нужной регистрационной записи и серверных секретов всё равно делает неизбежным офлайн-перебор пароля пострадавшего пользователя.
  • Разные пользовательские OPRF-ключи могут происходить от одного oprf_seed. Независимые зерна, ложные ответы, пороговая схема и повторная регистрация меняют радиус ущерба, но создают собственные обязательства.

Самая удобная фраза о безопасности может быть правдивой и всё же описывать не тот масштаб.

«Сервер никогда не видит пароль» верно для OPAQUE. Но из этого не следует, что серверная сторона лишена корневого секрета, что один взлом затрагивает только одну учётную запись или что смена криптографии завершается обновлением программы.

RFC 9807, опубликованная в июле 2025 года, описывает усиленный протокол обмена ключами с парольной аутентификацией. Клиент сочетает oblivious pseudorandom function, конверт восстановления и аутентифицированный обмен ключами. Он доказывает знание пароля и получает общий сеансовый ключ, не передавая сам пароль даже при регистрации.

Статус документа тоже требует точности. Карточка RFC Editor и Datatracker относят его к информационным RFC потока IRTF и консенсусу Crypto Forum Research Group. Текст прямо говорит, что это не продукт IETF и не стандарт. Ссылка на каталог IETF помогает найти источник, но не превращает исследовательский документ в Standards Track.

Что именно перестаёт получать сервер

В обычной схеме TLS 1.3 защищает пароль в пути и отдаёт его приложению. После завершения канала секрет может попасть в журнал, память или посторонний компонент. Защита транспорта не управляет получателем.

В OPRF из RFC 9497 сервер держит ключ функции, а клиент посылает ослеплённый вход. Клиент получает выход, сервер не узнаёт ни вход, ни выход. Затем клиент выполняет растяжение и создаёт конверт со своим аутентификационным материалом.

Вход состоит из KE1, KE2 и KE3. Явная аутентификация клиента завершается только третьим сообщением. Отправленный KE2 ещё не означает успех: доказательство появляется после корректного KE3 и ServerFinish. Общий session_key и доступный только клиенту export_key тоже имеют разные функции. Ни один не заменяет решение приложения о разрешении операции.

Перебор остаётся после компрометации

Исходная работа OPAQUE честно фиксирует предел: в одно-серверном aPAKE после утечки файла и соответствующих секретов офлайн-перебор индивидуального пароля неизбежен. OPAQUE не даёт заранее построить полезную таблицу для предсказуемого отображения. Атакующему приходится ждать утечки и оплачивать каждую гипотезу после неё.

KSF повышает цену. RFC 9807 предлагает Argon2id или scrypt; RFC 9106 описывает Argon2. Но вычисление выполняет клиент. Рост памяти и времени замедляет атаку и одновременно нагружает дешёвый телефон, встроенное устройство и восстановление доступа. Нужны хвостовые задержки и ошибки на слабейших поддерживаемых клиентах, а не среднее на ноутбуке.

OPAQUE не устраняет онлайн-попытки, слабые пароли и скомпрометированные устройства. Он не делает взлом сервера безвредным. Он не передаёт серверу повторно используемый секрет, блокирует предварительные вычисления в своей модели, даёт взаимную аутентификацию и прямую секретность. Узкая гарантия сильнее универсального лозунга.

Общий корень разных ключей

Сервер создаёт пару AKE и oprf_seed. Зерно вместе с уникальным идентификатором порождает отдельный OPRF-ключ клиента. Листья различны, корень может быть один.

RFC 9807 рекомендует общее зерно для своей защиты от перечисления и одновременно предупреждает: его утечка компрометирует безопасность всех зависящих клиентов. Поэтому схема «ключ на пользователя» может быть математически верной и операционно неполной.

Исследование (Strong) aPAKE Revisited рассматривало многопользовательскую версию линии черновика. Зерно само по себе не открывает все пароли. Файл одного пользователя раскрывает глобальный корень; из него вычисляется OPRF-ключ другого; одна обычная сессия с честным сервером даёт дополнительный материал для офлайн-проверки второго пользователя. Финальная RFC цитирует эту работу и фиксирует межпользовательское следствие.

Если указанная защита от перечисления не нужна, можно хранить независимые зерна. Тогда соответствие клиента и зерна должно одинаково работать при регистрации, входе, репликации и восстановлении. Ошибка способна выдать существование записи или заблокировать владельца. Разделение корней создаёт новое состояние, которое тоже надо контролировать.

Принцип приоритета работающего кода переводит этикетку в проверку: какой администратор, процесс, резервная копия или анклав может восстановить ключи скольких пользователей?

Скрытие существования аккаунта — отдельная цель

Для неизвестного идентификатора сервер может создать ложный CredentialResponse. Клиентский masking_key, переданный при регистрации, шифрует ответ, чтобы реальный и симулированный случаи выглядели одинаково. Разница во времени или ошибках всё равно станет оракулом.

Регистрация не защищена таким способом: она вынуждена различать новый и существующий идентификатор. Её надо ограничивать. Ложный ответ также может стать ресурсной поверхностью, если обходится серверу дешевле, чем запрос клиенту.

Передача masking_key требует конфиденциального и аутентифицированного регистрационного канала. RFC упоминает TLS и HPKE для добавления конфиденциальности поверх аутентифицированного канала. Скрытый пароль не оправдывает слабую церемонию установки остальных секретов.

Выбор общего или независимого зерна балансирует приватность существования, поперечный ущерб, согласованность и сложность. Подход минимальной общей спецификации и локального будущего решения уместен: протокол задаёт совместимость, оператор обосновывает свою угрозу перечисления и архитектуру хранения.

Три области хранения

OPRF-зерно, закрытый AKE-ключ и база RegistrationRecord дают разные возможности. AKE-ключ может оставаться неэкспортируемым в HSM, который выполняет лишь нужную операцию. Это способно предотвратить подмену сервера после утечки зерна и конвертов, но не отменяет перебор, доступный с OPRF-материалом и записями.

Карта должна отдельно показать, кто вычисляет OPRF и для скольких аккаунтов, кто вызывает AKE и кто копирует записи, связывая их с личностями. Три сервиса с одним администратором и резервной копией — один сейф.

Пороговый OPRF изменил бы первую границу: атакующему нужны достаточные доли или онлайн-доступ. Разнесение OPRF- и аутентификационных серверов означает, что без базы записей даже долей недостаточно. Исходная работа допускает конструкцию, но RFC 9807 оставляет реализацию вне области. Поддержка порога не доказывает независимость хранителей.

HKDF, отображение на кривые из RFC 9380 и требования PAKE из RFC 8125 — необходимые детали, а не сертификат всей системы.

Миграция означает повторную регистрацию

Смена KSF, алгоритмов или связанного с RegistrationRecord материала, например открытого ключа сервера, требует новой регистрации. Смена пароля тоже создаёт запись с новой случайностью. Так обнаруживается реальная цена криптографической гибкости.

Новая версия сервера не обновляет спящие аккаунты, старые клиенты, неудачное восстановление и данные под прежним export_key. При миллионах записей конфигурация превращается в зависимость: без участия пользователя из старой области риска не выйти.

Уровни реальности разделяют факты: новая программа работает; записи мигрировали; старые секреты выведены. Последнее верно лишь после прекращения приёма всех старых записей и обходных путей.

Доказательство — реестр когорт: подходящие аккаунты, новые записи, всё ещё действующие старые, спящие пользователи, ошибки восстановления, несовместимые с новой KSF устройства, данные под старым export key, обращения к fallback и дата фактического отключения прежних OPRF-, AKE- и record-материалов.

OPAQUE сильно отвечает на ограниченный вопрос: можно ли аутентифицировать пароль, не отдавая его серверу и не допуская повторно используемой предвычисленной атаки? Да, в заявленной модели. Ошибка руководства — превратить ответ в общий сертификат.

Пароль исчез из поля зрения сервера. Власть переместилась в корни вывода, записи, закрытые операции, симуляцию, ресурсы клиента и миграцию. Только проверяемая карта превращает перемещение в реальное сокращение риска.

Sources