Кратко

  • RFC 9106 описывает входы, выбор параметров и тестовые векторы Argon2 1.3, но не сертифицирует производительность конкретной системы аутентификации.
  • Надёжное операционное свидетельство отделяет стоимость одного вызова от конкурентности, пика памяти, очереди, поведения при перегрузке и доли записей со старыми параметрами.

Один запрос на вход приходит к верификатору. В записи указаны Argon2id, версия 19, уникальная соль, 64 MiB памяти, три прохода и четыре линии. Вычисление завершается успешно. Но главный вопрос для сервиса остаётся без ответа: что произойдёт, когда сотни таких проверок одновременно потребуют память и время?

RFC 9106 не прячет эту границу. Её процедура выбора сначала спрашивает, сколько памяти может позволить один вызов и сколько времени он может занять. Затем меняется число проходов; если даже один проход слишком медленный, предлагается уменьшить память. Безусловного знака качества здесь нет. Параметры выбираются внутри ресурсного контура оператора.

Контур входит прямо в вычисление. Пароль P, соль S, параллелизм p, длина тега, память m, число проходов t, версия и тип поступают в начальный хеш вместе с необязательными secret и associated data. Память разбита на блоки по 1 KiB и распределена между p линиями. Линии могут двигаться параллельно внутри сегмента, но синхронизируются на границах; дополнительные проходы вновь обходят матрицу. Фраза «мы используем Argon2id» не называет величины, определяющие эксплуатационную цену.

Спецификация рекомендует уникальную для каждого пароля соль длиной 16 байт. Она разделяет одинаковые пароли и не даёт свести их к одной повторно используемой цели. Но соль не является секретом и сама не задаёт стоимость попытки. Для каждой записи нужно хранить точные версию и набор параметров — иначе нельзя корректно проверять старые записи и повышать их стоимость.

Две рекомендации показывают компромисс. Первая использует 2 GiB, один проход и четыре линии. Вариант для ограниченной памяти — 64 MiB, три прохода и четыре линии. Документ также приводит примеры для процессора 2 GHz, включая серверную аутентификацию с четырьмя ядрами, восемью линиями, 4 GiB и 0,5 секунды. Это ориентиры при названных предпосылках, а не обещания для контейнеров, виртуальных машин, NUMA, распределителей памяти, пропускной способности и хвостов задержки.

Тестовые векторы доказывают ещё меньше. Они позволяют сверить промежуточные блоки и итоговый тег при фиксированных входах — например, 32 KiB, три прохода и четыре линии. Совпадение подтверждает арифметическую совместимость для случая. Оно ничего не говорит о пике resident memory, отмене, очистке памяти, вмешательстве планировщика, росте очереди и действиях при отказе выделения.

В этом разрыве сильный на бумаге хеш превращается в слабую эксплуатационную политику. Произведение 64 MiB на число одновременных вызовов — лишь плановая граница, не наблюдение. Накладные расходы библиотеки, повторное использование аллокатором и полоса памяти меняют результат. Сервис должен решить, что делать у границы: ставить в очередь, отклонять, ограничивать, завершать по тайм-ауту, сбрасывать другую работу или закрываться безопасно. Молчаливый переход на более дешёвый путь меняет утверждение о защите; исчерпание процесса превращает защитную стоимость в оружие против доступности.

Миграция создаёт вторую иллюзию. Текущее руководство NIST требует сохранять схему и cost factor для каждого пароля, чтобы их можно было повысить. Возможность не означает завершение. Новое значение по умолчанию может затронуть лишь новые пароли и аккаунты, вошедшие после изменения. Настоящая поверхность контроля — распределение сохранённых наборов, триггер rehash, неудачные обновления и остаток, всё ещё проверяемый по старому бюджету.

Вывод о цене атаки тоже ограничен. Memory-hard функция повышает ресурсы на одну попытку и навязывает противнику компромисс времени и памяти. Она не раскрывает качество паролей, объём утечки, оборудование нападающего, цену энергии или ценность аккаунта. RFC 9106 прямо называет себя информационным результатом IRTF, а не документом Internet Standards Track, и предупреждает, что исследовательские результаты могут не подходить для внедрения. Её авторитет — точность алгоритма, не сертификат для ненаблюдаемой системы.

Здесь проходит и граница с материалом о RFC 9807. В OPAQUE функция растяжения находится у клиента и возникает вопрос невидимости пароля, хранения корня OPRF и миграции записей. Здесь рассматривается обычный серверный верификатор и способность оплачивать соль, память, проходы и линии при множестве одновременных вызовов. Первое — карта протокола и доверия, второе — журнал ёмкости и доказательств.

Операционный чек должен фиксировать точные тип и версию, политику соли, m, t, p, длину тега и optional secret; библиотеку и класс оборудования; холодные и прогретые перцентили задержки; пик памяти вызова и процесса; активные проверки; глубину очереди; отказы и тайм-ауты; отмену и очистку; давление CPU и полосы памяти; распределение параметров; успехи и ошибки rehash; ограничение, восстановление и режим отказа. Успешный хеш — начало этой цепочки, а не её конец.

Источники

Спецификация и статус: RFC 9106, запись RFC Editor, IETF Datatracker и статья Argon2. История проекта: Password Hashing Competition. Требования к верификаторам: рекомендации NIST по аутентификаторам и анализ паролей NIST. Соседняя протокольная граница: RFC 9807. Аналитическая рамка: Minimum Initial Specification, Reality Layers и Running-Code Primacy.