Кратко

  • RFC 9591 задаёт два раунда FROST, в которых пороговый набор участников создаёт доли, а координатор агрегирует их в подпись (R, z) под групповым открытым ключом.
  • В конечной подписи нет списка участников, отдельных долей и деловых решений. Для атрибуции нужны аутентифицированный канал, целостный протокол сессии и версия правил допуска.

Одна подпись скрывает множество допустимых составов

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

Именно так достигается совместимость. Некоторые наборы FROST дают подписи, которые обычный проверяющий Ed25519 или Ed448 принимает как результат одного подписанта. Секрет распределён внутри, а внешний интерфейс остаётся компактным.

Поэтому действительная групповая подпись и коллективное одобрение — разные утверждения. Криптография подтверждает операцию группового ключа над байтами. Организационное решение требует имён, мандата и смысла подписанного объекта.

Состав выбирается за пределами протокола

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

RFC прямо относит выбор координатора и набора подписантов к внешнему механизму. Возможен режим без единого координатора, когда все обмениваются данными друг с другом. Но и там приложение определяет членство, сообщение, срок и условие выпуска.

Математический идентификатор не равен личности или должности. Связь с человеком либо сервисом должна включать версию реестра, срок полномочий, открытый ключ доли и отзыв. Увольнение не удаляет секретную долю автоматически.

Первый раунд создаёт одноразовое состояние

Участник генерирует две секретные nonce-величины и публикует два обязательства. Во втором раунде он получает сообщение и полный упорядоченный список обязательств. Групповой ключ, сообщение, список и идентификатор входят в коэффициент привязки, после чего вычисляется доля подписи.

Nonce нельзя применять в двух вызовах sign; после использования их необходимо удалить. Повтор может привести к полному восстановлению секретной доли. Откат хранилища к старому снимку способен восстановить доступность, одновременно вернув уже использованное опасное состояние.

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

После агрегации список нельзя извлечь обратно

Координатор суммирует доли и публикует R и z. Каноническое кодирование не содержит порога, идентификаторов, обязательств, долей и локальных вердиктов. Если протокол сессии уничтожен, корректная подпись его не восстановит.

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

Молчание имеет другую семантику. FROST не распознаёт самостоятельно отказавшегося участника. Приложение может зафиксировать доставку запроса, истечение срока и отсутствие ответа, но не должно объявлять по этим данным злой умысел. Реакция на нарушителя остаётся вне спецификации.

Правильная доля не доказывает деловое разрешение

RFC рекомендует проверять входное сообщение средствами приложения, чтобы участники не стали оракулами подписи. Для транзакции могут потребоваться синтаксис и намерение заинтересованных сторон. Для TLS участник может запросить исходные сообщения рукопожатия, а не доверять переданному хешу transcript.

Корректная доля показывает, что секретная доля была использована над протокольным сообщением. Она не доказывает, что интерфейс показал тот же объект, политика разрешала действие, роль оставалась действующей, а принимающая система исполнила именно проверенный запрос.

Надёжная цепочка связывает канонический объект, подписанные байты, версию политики, локальное решение, личность участника, проверку доли, агрегирование, выпуск и конечное действие. Одно поле «одобрено» не заменяет эти связи.

Идентифицируемое прерывание не означает устойчивость

Неверная доля или неучастие способны остановить сессию. RFC 9591 прямо говорит, что FROST не обеспечивает robustness. Для более устойчивой асинхронной работы ROAST рассматривается как отдельная обёртка. FROST также не является постквантовым: его безопасность зависит от трудности дискретного логарифма.

Документ опубликован как Informational в потоке IRTF и выражает консенсус CFRG. Это не стандарт IETF и не обязательство внедрения. Тест-векторы и поддержка библиотеки не доказывают производственный реестр участников, аутентификацию каналов, защиту nonce, политику и архив.

В логике Lu Heng реальность работающего кода должна ограничивать размер вывода. Корректная подпись — исполнимый криптографический факт. Формулировка «совет уполномочил» относится к мандату и требует собственного основания. Смешивать эти слои — значит приписывать примитиву власть, которой в нём нет.

Источники