Кратко

  • Редакция 12 проекта BBS позволяет владельцу доказать знание одной подписи над множеством сообщений, раскрыв лишь выбранные. Несвязываемость относится к рандомизированному значению proof: header, presentation_header, раскрытые значения, число и позиции сообщений, ключ подписанта, сетевой адрес и данные приложения могут по-прежнему связывать предъявления.
  • Успешный ProofVerify — ограниченная криптографическая квитанция. Он сам по себе не доказывает личность человека, проверку фактов при выдаче, текущий статус, полноту, авторизацию, несвязываемость всей сессии или результат действия.

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

Именно поэтому важен draft-irtf-cfrg-bbs-signatures-12. Он не только описывает сильную многосообщенческую подпись и zero-knowledge proof of knowledge, но и ограничивает обещание правильным объектом. Перечень внешних каналов корреляции — не примечание, а часть эксплуатационного контракта.

Конкретные векторы проверяют реализацию, но не приватность среды

Редакция 12 подана 28 сентября 2026 года как активный документ CFRG в потоке IRTF с предполагаемым статусом Informational. Это всё ещё Internet-Draft, а не опубликованный RFC, не Standards Track и не свидетельство внедрения или совместимости конкретного продукта.

По сравнению с редакцией 11 в тексте появились реальные константы ciphersuite, скаляры, генераторы, подписи и fixtures вместо шаблонных вставок. Разработчик может прогнать фиксированные входы и сравнить выходы побайтно. Это весомое доказательство для математики, сериализации и интерфейса.

Но fixture заранее задаёт ключ, сообщения, заголовки и тестовую случайность. В производстве остаются вопросы: кто распространил ключ, видели ли все одну key view, сколько людей разделяют header, не повторилось ли состояние RNG после fork или snapshot, какие идентификаторы добавили кошелёк, транспорт и Verifier. Вектор этого не измеряет.

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

У слова VALID должна быть точка

BBS подписывает упорядоченный список сообщений одной подписью постоянного размера. Holder затем создаёт рандомизированное доказательство знания и показывает выбранные сообщения. Verifier получает публичный ключ, proof, связанный с подписью header, связанный с текущей презентацией presentation_header, раскрытые значения и исходные индексы.

Успех означает: Prover знает действительную BBS-подпись под данным ключом; видимые сообщения находились на указанных местах; оба заголовка включены в доказательство; скрытая подпись и нераскрытые значения из proof не извлечены.

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

Существующий материал о RFC 9901 уже владеет границей SD-JWT между корректным раскрытием и полным досье. Здесь граница иная: BBS-proof может оставаться криптографически несвязываемым, пока вся презентация формирует устойчивый отпечаток.

Header от Signer может стать постоянным именем

Проект различает два заголовка. header выбирает Signer; он связан с исходной подписью и каждым производным proof и всегда раскрывается Verifier. Он полезен для общего контекста — приложения, домена, версии с малой кардинальностью, — но опасен при индивидуальном значении.

Случайный credential ID, адрес электронной почты, номер устройства или точное время истечения повторяются в каждой презентации. Рандомизация proof не защищает от такого простого join key. Поэтому проект требует низкоэнтропийное значение, общее для большой группы.

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

Квитанция Issuer должна хранить точные байты, правило генерации, ожидаемую и реальную численность, связанный ключ и исключения. Holder не может заменить уже подписанный header, поэтому ответственность остаётся у того, кто его выбирает.

Presentation header связывает challenge, а не придумывает его смысл

presentation_header выбирается для одного proof. Он может содержать nonce Verifier, audience, domain, срок или сообщение, подписываемое Prover. Действительный proof подтверждает целостность и привязку значения.

Свежесть требует внешнего состояния. Verifier должен знать источник nonce, сессию, audience, срок и факт использования. Неинтерактивной схеме нужен иной способ доказать уникальность. Новая случайная строка всё ещё может относиться к чужой транзакции.

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

Журналу нужны источник, сессия, audience, создание, истечение и consumed state с ограниченным сроком хранения. Один флаг «nonce valid» не восстанавливает решение; вечное хранение каждого challenge создаёт новую базу слежения.

Форма скрытых данных остаётся данными

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

Редкая комбинация индексов становится отпечатком. При объединении журналов нескольких Verifier множество уменьшается. Проект рекомендует общую длину через padding и стабильный порядок. Это управление популяцией, а не эстетика кодирования.

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

Публичный ключ может разделить людей до создания proof

Каждый proof проверяется под ключом Signer. Если ключ обслуживает одного человека или малую когорту, всякая презентация под ним указывает на эту когорту, хотя сами proof values не связываются.

Это бывает без злого умысла: региональные ротации, canary, изоляция инцидента, унаследованная иерархия. Злонамеренный Issuer может показать избранным Holder отдельную key view и получить скрытую метку.

Квитанция включает байты и ID ключа, канал публикации, активацию, вывод, плановую и фактическую популяцию, доказательство согласованности. Механизмы key consistency — один путь; общая обязанность состоит в недопущении выборочной фрагментации представлений.

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

Раскрытая истина может быть самым сильным идентификатором

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

BBS подтверждает подлинность, но не необходимость. Цель, пропорциональность, срок хранения и альтернативы принадлежат политике сервиса. Запрос точной даты вместо доказательства совершеннолетия уничтожает приватность без нарушения алгоритма.

Range proof и set-membership proof могут уменьшить раскрытие, но это отдельные конструкции. Базовый BBS не превращает возраст в порог и не доказывает отсутствие отзыва лишь потому, что идентификатор скрыт.

Случайность — материал конфиденциальности

ProofGen требует нескольких независимых, уникальных и равномерных скаляров. Повтор, предсказуемость или известная связь могут раскрыть скрытые сообщения или подпись. Proof способен оставаться синтаксически правильным после утраты приватности.

Проект описывает и канал эксфильтрации: манипуляция несколькими случайными битами кодирует данные в нормальном выводе. Детерминированный RNG с уникальным равномерным seed может ограничить канал в чувствительных системах; доверенная энтропия и хранение seed всё равно нужны.

Производственная запись называет RNG, build библиотеки, путь seed, health tests, границы процесса и устройства, fork, snapshot restore и реакцию на сбой. «Системный RNG» — архитектурное намерение, не квитанция исполнения.

Отдельно проверяются десериализация ключа, subgroup checks, domain separation, защита от side channels и единая обработка сообщений. Совпадение с fixtures не доказывает эти свойства автоматически.

Не заимствовать свойства соседних расширений

Blind BBS Signatures — отдельный протокол, позволяющий Signer подписывать сообщения Holder, скрытые commitment. Селективное раскрытие базового BBS скрывает от Verifier при предъявлении; оно не доказывает, что Issuer не видел значение при выдаче.

BBS per Verifier Linkability добавляет контекстный pseudonym. Один Verifier может узнавать повторные визиты, а разные контексты должны оставаться несвязанными. Базовый BBS не создаёт такой стабильный pseudonym сам.

W3C bbs-2023 — профиль Verifiable Credentials с обязательными и выборочными pointers, преобразованием и опциями holder binding или pseudonym. Закупка должна отдельно назвать revision, ciphersuite, интерфейс, расширение и профиль. «Поддерживает BBS» недостаточно.

Квантовая угроза разделяет подлинность и сокрытие

Подлинность BBS зависит от дискретного логарифма и не является post-quantum. Криптографически значимый квантовый компьютер сможет получить секрет Signer, создать подписи и валидные proofs на выбранные сообщения.

Проект отдельно утверждает информационное сокрытие нераскрытых сообщений и подписи в уже созданном proof. Даже неограниченное вычисление с секретом Signer не извлекает их. Это everlasting privacy proof, а не quantum-safe ярлык системы.

Миграция имеет две шкалы времени. Подлинность нужно заменить до достижения угрозой срока ценности решения. Старые transcripts могут сохранять секрет, тогда как headers, видимые значения, IP и журналы остаются связываемыми. Ротация не удаляет копии.

Квитанция охватывает весь разговор

Минимальная цепочка разделяет: версию и ciphersuite; источник ключа и согласованность view; blind или обычную выдачу; header и когорту; схему, порядок и padding; значения и индексы; presentation header, nonce, audience и свежесть; proof и вердикт; RNG; parser, subgroup, domain separation; метаданные сети и устройства; статус/отзыв; policy; авторизацию; действие; эффект; хранение; миграцию.

Централизация не нужна. Issuer, wallet, Verifier, приложение, security и privacy хранят своё решение и связывают его ограниченным ID транзакции. Minimum Initial Specification Лу Хэна оставляет общий слой минимальным. Разделение слоёв реальности не позволяет zero knowledge присвоить полномочие авторизации. Running-Code Primacy спрашивает, какие ключ, схема, RNG, binary и log path реально работали.

BBS обещает сильное свойство с чётким объектом. Риск появляется, когда организация добавляет к фразе «вся система», не добавляя новых доказательств.

Источники