Кратко

  • 7 сентября 2026 года CFRG выпустила редакцию 14 draft-irtf-cfrg-pairing-friendly-curves. Это действующий Internet-Draft исследовательской группы IRTF, предназначенный для публикации как Informational; он не является RFC или стандартом IETF.
  • Редакция задаёт нормативную сериализацию и десериализацию точек BLS12-381 и BLS48-581, а также скаляров этих кривых и BN462. Декодер проверяет каноничность координат, кривую и подгруппу, после чего возвращает элемент группы либо INVALID.
  • У вызывающего протокола остаются три решения: какие формы точек принимать, разрешать ли единичный элемент и разрешать ли нулевой скаляр. Последние два решения независимы.
  • В сравнении с редакцией 13 новый текст убирает общую рекомендацию отклонять единичный элемент по умолчанию, отделяет от неё правило для нуля и добавляет явный выбор формы точки. Нормативной кодировки точек BN462 нет намеренно: изученные практики не сошлись.
  • Daniel Kade предлагает публиковать семипунктный профиль допустимости. Это аналитическая рекомендация статьи, а не требование проекта или CFRG.

Математическая корректность ещё не завершает контракт

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

Редакция 14 уточняет первый слой. Процедура десериализации точки возвращает элемент группы или INVALID. Координата, равная модулю поля или превышающая его, отклоняется, а не молча приводится по модулю; благодаря этому у значения не возникает дополнительного байтового представления. Затем проверяются уравнение кривой и принадлежность подгруппе. Одинаковая длина представления двух типов точек не делает допустимым декодирование через чужую кривую.

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

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

Три переключателя нельзя заменить одним строгим режимом

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

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

Третье решение относится к нулевому скаляру и принимается отдельно. Редакция 13 называла отклонение единичного элемента рекомендуемым значением по умолчанию и связывала обращение с нулём с той же протокольной политикой. Редакция 14 разрывает эту связь. RFC 9591 показывает различие на практике: десериализация элементов отклоняет единичный элемент, а десериализация скаляров не добавляет равноценного запрета нуля.

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

BN462 обозначает предел общего формата

Проект определяет кодировку точек BLS12-381 и BLS48-581, но не точек BN462. Модуль базового поля BN462 занимает 462 бита. В 58 байтах всего 464 бита, то есть свободны только два, тогда как общему сжатому формату нужны три вида метаданных.

Информационное приложение перечисляет несовместимые подходы в существующем ПО: байт типа в духе SEC1, отдельный байт флагов и упакованные представления без той же договорённости о метаданных. Авторы пишут, что изученные спецификации не требуют кодировки точек BN462, а практика не пришла к единому виду. Поэтому редакция 14 не объявляет ни один подход нормативным общим маршрутом.

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

Локальная свобода требует видимой записи

История разработки объясняет стремление к общему ядру. Issue 74 в репозитории CFRG требовал одного авторитетного определения сериализации вместо расходящихся копий. Pull request 108 внёс в редакцию 14 именованные процедуры, проверки принадлежности, решения вызывающего протокола и работу над тестовыми векторами. В рассылке CFRG авторов зависимых документов предупредили о новой секции. Проекты подписей BBS и представлений ключей BLS в COSE показывают, что такая зависимость уже практическая.

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

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

Название и состав профиля — предложение Daniel Kade; редакция 14 их не требует. Задача не в унификации локальных решений, а в том, чтобы до развёртывания было понятно, кто, для какой версии и с какими последствиями их принял.

Источники