Модель безопасности

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

Эта страница — модель угроз для самого стандарта: модель доверия, в рамках которой работает соответствующий стандарту верификатор; свойства приватности неподписанного запечатанного подтверждения существования; криптографические обязательства, которые ДОЛЖНА соблюдать каждая реализация; и те пределы, которые формат записи не преодолевает — и не может преодолеть. Здесь не описывается операционная безопасность какого-либо конкретного развёртывания; описывается то, что формат гарантирует любому, кто реализует его правильно.

Модель доверия

Полагающаяся сторона, которая проверяет доказательство Label 309, задаёт узкий вопрос: существовали ли эти байты не позднее времени блока и зависит ли этот вердикт от добросовестности кого-либо, кроме самой Cardano? Стандарт устроен так, чтобы ответ на вторую половину вопроса всегда был «нет». Посредника, управляемого издателем, нет ни на одном шаге: шлюз цепочки и шлюз хранилища, к которым обращается верификатор, — это недоверенные источники данных, проверяемые криптографически там, где это возможно, и сверяемые на включение и финальность.

Чему верификатор доверяет:

• Публичной цепочке Cardano. Транзакция, её метаданные под меткой 309 и время её блока — это факты, реплицированные на каждом узле Cardano. Верификатор считывает их через шлюз по своему выбору и может сверить их сразу через несколько.
• Байтам содержимого — когда проверяется заявление о содержимом. Хеш в записи фиксирует конкретную последовательность байтов. Верификатор, у которого эти байты есть, пересчитывает хеш и сравнивает его — не веря никому на слово, что байты совпадают.

Чему верификатор не доверяет:

• Издателю. В Label 309 нет поля issuer. Опубликовать любую запись может любой кошелёк; действительность записи не зависит от того, кто её отправил. Верификатор никогда не спрашивает «заслуживает ли доверия этот издатель?» — этому вопросу нет места в модели. См. инвариант независимости от издателя на странице Введение.
• Серверу или домену. Ни один шаг проверки не обращается к сервису, которым управляет издатель. Нет ни канонического реестра, к которому надо обращаться, ни статусной точки доступа для опроса, ни удостоверяющего органа идентичности, к которому привязывался бы ключ.
• Оператору шлюза. Шлюзы Cardano, Arweave и IPFS, через которые читает верификатор, взаимозаменяемы, а возвращаемое ими содержимое можно проверить независимо (см. ниже). Шлюз — это транспорт, а не корень доверия.

Почему шлюзы не являются корнем доверия

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

• Шлюз не может подделать запись с действительной подписью — у него нет закрытого ключа подписавшего, а верификатор сам пересчитывает подписанные байты и проверяет их. См. Подписи.
• Шлюз не может незаметно подменить содержимое под URI с адресацией по содержимому: ipfs:// CID — это мультихеш, который верификатор пересчитывает из полученных байтов, а идентификатор транзакции ar:// фиксирует данные под консенсусом Arweave. В соответствующей стандарту записи ончейн-карта hashes — это вторая, независимая привязка к открытому тексту, пересчитываемая в момент загрузки.
• Шлюз, который утаивает транзакцию или искажает сведения о том, насколько глубоко она погребена, реализует сценарий отказа в обслуживании, а не подделки. Верификатор, который читает сразу через несколько шлюзов и прерывается при расхождении, превращает «один нечестный шлюз» в «сговор всех шлюзов, которые он выбрал», — а это под его контролем.

Глубина блока — сколько подтверждений требует верификатор, прежде чем считать запись окончательно зафиксированной, — это политика верификатора, а не значение, которое предписывает Label 309. Стандарт не задаёт никакой числовой глубины; полагающаяся сторона сама устанавливает порог под собственную терпимость к риску. См. Проверка.

Свойства приватности запечатанного подтверждения существования

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

Анонимность отправителя для неподписанного запечатанного подтверждения существования

Неподписанное запечатанное подтверждение существования — запись, несущая enc и не несущая sigs, — НЕ ДОЛЖНА раскрывать идентичность отправителя в блокчейне. Её байты на проводе ДОЛЖНЫ быть независимы от долговременных ключей отправителя.

Это обеспечивается структурно:

• На проводе нет ключа подписавшего. Ключ идентичности отправителя попадает в цепочку только через запись в sigs. Запись без sigs не несёт со стороны подписавшего ни одного байта. Авторство — дело добровольное; анонимность задана по умолчанию. Долговременные ключи отправителя X25519 и Ed25519 никогда не появляются в неподписанной записи.
• Свежая инкапсуляция для каждого слота. Каждый слот получателя несёт материал KEM, отдельный для каждой записи и каждого слота, заново сгенерированный в момент запечатывания, — эфемерный открытый ключ X25519 в slot.epk на пути x25519 или шифртекст X-Wing в slot.kem_ct на пути mlkem768x25519. Он никак не связан с долговременным ключом отправителя и не выдаёт ничего, что связывало бы записи с общим автором.
• Перемешанные слоты. Перед публикацией массив слотов перемешивается с помощью CSPRNG, так что порядок позиций («первым стоит основной получатель») не несёт никакого сигнала.

Тот, кто позднее подпишет запись, раскрывает свой ключ идентичности только в этой записи; ни в одной более ранней неподписанной записи он не появляется, и никакая операция не сопоставляет материал KEM прежних слотов с автором. Ключи идентичности X25519 и Ed25519 выводятся из мастер-сида через разные контекстные строки HKDF, а открытый ключ Ed25519 не может вывести открытый ключ X25519 и не может ему соответствовать, так что подпись одной записи никогда не связывает неподписанные. Согласие на авторство — это шаг вперёд, а не ретроактивная деанонимизация.

Этот инвариант покрывает только байты записи label-309. Платящий комиссию адрес Cardano во входах транзакции, сетевая идентичность создателя записи, как её видит шлюз, и любые метаданные во внецепочечном блобе шифртекста — за пределами формата записи: Label 309 живёт в метаданных, а не во входах транзакции, и не может защитить от корреляции по плательщику комиссии. Создатель записи, которому нужна анонимность плательщика комиссии, должен решать это на уровне построения транзакции.

Несвязываемость получателей

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

Первая действует для обоих KEM и для любого наблюдателя:

• Получатели не видят друг друга. Каждый слот — это независимо обёрнутый ключ. Получатель, открывший свой слот, не узнаёт ничего ни о каком другом слоте и не может сказать, кто ещё был адресатом.
• На проводе нет открытых ключей получателей. Появляются только инкапсуляция по слоту (epk или kem_ct) и обёрнутый ключ. Наблюдатель без ключей-кандидатов не может перечислить получателей — он узнаёт лишь число слотов, семейство KEM (enc.kem) и различие «запечатано или открыто».

Вторая — анонимность получателя против противника, у которого уже есть набор открытых ключей-кандидатов получателей и который хочет проверить, адресован ли слот кому-то из них, — это более сильное, специфичное для KEM свойство, и стандарт заявляет его только для классического пути:

• x25519 приватен к ключу. epk каждого слота — это свежий эфемерный открытый ключ, статистически независимый от ключа получателя. По одним лишь epk и wrap противник, держащий ключи, не может решить, какому кандидату (если вообще какому-либо) адресован слот, без подходящего закрытого ключа.
• mlkem768x25519 этого не заявляет. Анонимность получателя против противника, держащего ключи, — это отдельное свойство, не вытекающее из IND-CCA-стойкости гибридного KEM, и оно не заявляется для пути X-Wing, пока и если не будет обосновано для X-Wing независимо. Развёртывание, чья модель угроз требует анонимности получателя против противника, держащего ключи, НЕ ДОЛЖНО полагаться ради этого свойства на гибридный путь. Честные утечки, перечисленные выше, — число слотов, семейство KEM, «запечатано или открыто» — одинаковы для обоих KEM; ничего сверх этого о получателях не раскрывается ни на одном из путей.

Привязка к открытому тексту

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

Независимость от повторной публикации

Подписи записи фиксируются в момент отправки её транзакции. У цепочки нет понятия «расширяемого набора подписавших», накапливающегося между транзакциями.

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

Тот, кто хочет подтвердить уже опубликованную запись, публикует собственную запись — ссылаясь на то же содержимое или указывая на предыдущую транзакцию через supersedes, — подписанную своим ключом. Он не дописывает свидетельство к чужой записи. Следовательно, злоумышленник, скопировавший байты подписанной записи в новую транзакцию, не становится соподписавшим исходной: он создаёт более позднее, дублирующее заявление с теми sigs, которые выбрал сам, тогда как более раннее время блока исходной записи остаётся каноническим свидетельством существования. Верификаторы и индексаторы НЕ ДОЛЖНЫ схлопывать две транзакции с идентичными телами записей в единое представление «объединённых подписавших»; иначе была бы искажена семантика времени блока для каждой записи, на которую опираются нижестоящие потребители.

Нормативные правила для реализаций

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

Никакой собственной криптографии

Label 309 намеренно допускает только хорошо изученные примитивы, каждый из которых назван в реестрах алгоритмов и реализован проверенной аудитом библиотекой. Реализация НЕ ДОЛЖНА вводить собственный симметричный шифр, KDF, конструкцию подписи или станзу обёртывания ключа. Формат записи — это композиция стандартных частей именно для того, чтобы его безопасность сводилась к безопасности этих частей.

Только аутентифицированное шифрование

Всё симметричное шифрование в Label 309 — слой содержимого и обёртка ключа для каждого слота — это AEAD. Нигде в формате нет неаутентифицированного режима шифрования. Расшифровщик, у которого проверка тега AEAD не прошла, ДОЛЖЕН выдать структурированную ошибку со стабильным кодом-дискриминатором и НЕ ДОЛЖЕН проваливаться к возврату неаутентифицированных байтов. Дополнительные аутентифицируемые данные входят в вычисление тега, поэтому неверный AAD приводит к точно такому же сбою, что и неверный ключ, — состояния частичного успеха, которое можно было бы прозондировать, не существует.

Сравнение секретов за постоянное время

Цикл сравнения, время работы которого зависит от секретных байтов, — это оракул. Каждая проверка равенства над секретом или тегом MAC/AEAD ДОЛЖНА выполняться за постоянное время:

• MAC набора слотов и любой тег HMAC: побайтовая утечка по времени на 32-байтовом MAC при состязательном повторении может восстановить тег.
• Проверка тега AEAD: операция decrypt нижележащей библиотеки уже возвращает сбой, не раскрывая, какой именно байт не совпал; реализации НЕ ДОЛЖНЫ переписывать эту проверку заново.
• Проверка подписи: используйте verify из библиотеки, а не самодельное уравнение.

Голый == / === над байтовыми массивами, затрагивающий любую из этих поверхностей, — это дефект. Проведение каждого такого сравнения через единственный типизированный помощник делает это свойство проверяемым при аудите.

Дисциплина постоянного времени распространяется на форму цикла пробной расшифровки, а не только на отдельные сравнения. Чтобы сохранить свойство сокрытия получателя, верификатор получателя ДОЛЖЕН обрабатывать все слоты в пределах прохода по одному закрытому ключу — постоянное число операций над слотами на ключ, без досрочного выхода на первом совпадении, — чтобы наблюдатель сетевого уровня с доступом к замерам времени не мог вывести, какой индекс слота развернул ключ и развернул ли вообще хоть один. Ключ-кандидат выбирается за постоянное время. Действительность доли X25519 фиксируется битом, не зависящим от секрета, kem_ok = NOT constantTimeEqual(shared, 0^32), вычисляемым сравнением за постоянное время, а не досрочным ветвлением; KEK затем — это выбор за постоянное время между настоящим KEK и фиктивным KEK, выведенным из нулевого общего секрета под той же солью и info, а kem_ok вплетается в приём слота (ok = kem_ok AND open_ok AND mac_ok), так что слот с недействительным ECDH не может быть принят, тогда как цикл всё равно выполняет идентичную работу. Массив слотов публикуется в перемешанном CSPRNG порядке, так что позиция на проводе и без того не несёт сигнала «первым стоит основной получатель»; вместе с проходом за постоянное время это означает, что наблюдатель узнаёт лишь число слотов. Получатель, держащий несколько закрытых ключей (например, архивные ключи после ротации идентичности), перебирает ключ × слот и МОЖЕТ замыкать накоротко между ключами — это утекает лишь слабый сигнал «какой ключ совпал», — но ДОЛЖЕН оставаться постоянным по времени на слотах любого отдельного ключа, заново выводя половину соли KEK, относящуюся к ключу получателя, на каждый ключ, поскольку оба KEM привязывают соль к канонической проводной кодировке этого ключа (ровно 32-байтовый открытый ключ X25519 или ровно закреплённая 1216-байтовая байтовая строка открытого ключа X-Wing — никогда неканоническая перекодировка).

Строгая проверка Ed25519

Подписи Label 309 ДОЛЖНЫ проверяться в строгом (каноническом) режиме. Нестрогий, кофакторный верификатор принимает определённые поддающиеся ковке подписи или подписи на ключах малого порядка, которые строгий верификатор отвергает, — а это позволило бы двум соответствующим стандарту реализациям разойтись в оценке одной и той же записи и нарушить свойство единого вердикта, на котором держится весь стандарт. Межъязыковой корпус соответствия фиксирует ровно один тестовый вектор с ключом малого порядка, чтобы поймать верификатор, соскользнувший в нестрогий режим. См. Подписи.

Никогда не логировать секретный материал

Байты сида, производные закрытые ключи, ключи шифрования ключей, ключи шифрования содержимого, материал, выведенный из парольной фразы, и расшифрованный открытый текст НЕ ДОЛЖНЫ попадать в логи ни на каком уровне. Редактирования по пути в конфигурации логгера необходимо, но само по себе недостаточно: значение, вложенное глубже, чем дотягивается шаблон редактирования, может проскользнуть незамеченным, поэтому реализации ДОЛЖНЫ также безусловно считать каждое значение байтового типа (Uint8Array, bytes и им подобные) непрозрачно отредактированным — даже для протокольно-публичных значений вроде nonce. Дешевле всего защитить тот секрет, который никогда не попадает в строку лога.

Гарантии конструкции запечатанного PoE

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

MAC набора слотов — это обязательство на ~128 бит

MAC набора слотов — это то, что делает восстановленный ключ содержимого обязательством к тому набору слотов, который совпал у получателя: злонамеренный отправитель не может сконструировать два различных набора слотов, которые один и тот же получатель примет как «свои». Требуемое здесь свойство — это ограниченное обязательство к ключу для ключа содержимого конверта в смысле RFC 9771 — восстановленный ключ привязан к единственному транскрипту слота, — а не полноценный обязующий AEAD над произвольными входами. Получатель выводит ключ из слота, а затем требует, чтобы этот же ключ воспроизвёл slots_mac над хешем транскрипта слотов, прежде чем счесть слот своим. Конкретно обязательство опирается на стойкость к коллизиям при многих ключах у

CEK ↦ HMAC-SHA-256( HKDF-SHA-256(CEK, info="cardano-poe-slots-mac-v1"), slots_hash )

для состязательно выбранных CEK и транскриптов. Поскольку противник управляет и CEK, и транскриптом, релевантная граница — это граница обобщённой коллизии (парадокс дней рождения) на 256-битном выходе HMAC: найти две пары (CEK, transcript), дающие один и тот же slots_mac, — это перебор на ~128 бит, а не уровень второго прообраза на 256 бит. Запас в 128 бит против обобщённой коллизии — это тот уровень безопасности, на который опирается это обязательство, и его достаточно для модели угроз.

Предварительное хеширование транскрипта в 32-байтовый slots_hash перед HMAC этого не ослабляет: коллизия slots_mac влечёт либо коллизию slots_hash (коллизию SHA-256), либо коллизию HMAC с ключом над равными slots_hash, и то и другое — на уровне ~128 бит. Доказуемость подмены самого транскрипта наследует границу коллизий SHA-256 в 2^128: любое изменение обязуемого поля заголовка или байта слота меняет slots_hash, а подделка неизменного slots_hash над другим транскриптом — это в точности тот самый перебор коллизии на ~128 бит. Прямое следствие: обёртывание по слотам не обязано быть обязующим AEAD — обязательство обеспечивает slots_mac, а не обёртывание, так что необязующее обёртывание (по умолчанию ChaCha20-Poly1305) здесь корректно.

Безопасность обёртывания с нулевым nonce опирается на уникальность ключей по слотам

Каждый слот обёртывает ключ содержимого под ключом шифрования ключей своего слота с помощью ChaCha20-Poly1305 при нулевом nonce. Нулевой nonce безопасен лишь потому, что ключ шифрования ключей задан для слота и используется ровно для одного обёртывания: каждый слот берёт свежую случайность KEM, поэтому ключ обёртывания уникален для слота с пренебрежимо малой вероятностью коллизии. Условие безопасности — это в точности уникальность ключей по слотам, и производитель НЕ ДОЛЖЕН вводить ничего, что могло бы повторить пару (key, nonce): сбой CSPRNG, повторяющий случайность KEM, детерминированную или коллизионную инкапсуляцию, повторное использование слота между записями, кэширование выведенного ключа по (получатель, эфемерный) или схлопывание двух появлений одного получателя в один слот.

Это чётко разделяется на проверяемую верификатором часть и обязанность, лежащую только на производителе:

• Дубликаты внутри записи отвергаются верификатором. Верификатор ДОЛЖЕН требовать, чтобы материал инкапсуляции был различен в пределах одного slots[] — все значения epk различны на пути x25519, все значения kem_ct различны на пути mlkem768x25519. Дубликат отвергается ещё до запуска любого примитива KEM или AEAD, с типизированным кодом ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Корпус соответствия проверяет это записью с двумя слотами, разделяющими один epk (или kem_ct), и требует такого отклонения. Это отклонение срабатывает лишь на повторяющемся epk / kem_ct; оно не запрещает запечатывать одному и тому же получателю дважды, поскольку честное дублирование всё равно берёт свежую случайность KEM по слоту для каждого появления (см. правило о нескольких совпадающих слотах ниже).
• Повторное использование между записями и между ключами — обязанность производителя. Ни один верификатор не может обнаружить, что производитель повторно использовал материал KEM в двух разных записях или для разных получателей; это лежит вне байтов одной записи и остаётся ответственностью производителя. Если бы будущая ревизия разрешила повторное использование ключей, нулевой nonce пришлось бы заменить свежим nonce в том же изменении.

Несколько совпадающих слотов: дополнение допустимо, конфликт CEK — нет

Закрытый ключ получателя МОЖЕТ правомерно совпасть более чем с одним слотом. Запечатывание одного и того же ключа содержимого одному и тому же получателю в нескольких слотах — каждый со свежими эфемералями по слоту — это правомерный приём дополнения и приватности, поднимающий видимое число слотов, не раскрывая, что два слота делят получателя. Он отличен от отклонения дубликата материала инкапсуляции внутри записи выше: честное дублирование берёт свежую случайность KEM, так что его epk / kem_ct различны, и оно никогда не задевает ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Поэтому верификатор ДОЛЖЕН выбирать ключ содержимого первого совпавшего слота и НЕ ДОЛЖЕН отклонять лишь потому, что совпало более одного слота.

Единственная аномалия, которую верификатор ДОЛЖЕН отклонить, — это два совпавших слота, восстанавливающих разные ключи содержимого, сравниваемые за постоянное время. Цикл пробной расшифровки несёт бит cek_conflict через все слоты и выдаёт единственный общий отказ, если какое-либо более позднее совпадение восстанавливает ключ, отличный от уже выбранного. Это защита в глубину: при свойстве обязательства выше совпадение с другим ключом и так неосуществимо — это в точности та коллизия при многих ключах, которую это свойство исключает, — так что проверка закрывается наглухо против сломанной реализации или будущего ослабления допущения. Негатив с другим ключом не конструируем как байтовый вектор (сконструировать его означало бы саму коллизию обязательства), поэтому свойство закрепляется поведенческими тестами на уровне реализации, а не фикстурой, наряду с позитивной фикстурой для правомерного дублирования получателя.

Ресурсные пределы парсера до любого примитива

Верификатор ДОЛЖЕН ограничивать ресурсы парсера ещё до запуска любого примитива KEM или AEAD, чтобы непомерно большой конверт не навязал работу прежде, чем будет отклонён. Контрольные границы — это MAX_SLOTS = 1024 слотов и 65536 байт для декодированного конверта enc, обе намного выше потолка метаданных транзакции Cardano в ~16 КиБ, ограничивающего любую честную запись, так что запись, превышающая любую из границ, недоформирована. Превышение числа отклоняется с кодом ENC_SLOTS_TOO_MANY, конверт сверх размера — с кодом ENC_ENVELOPE_TOO_LARGE. Это проверяемые верификатором, закреплённые на стороне развёртывания константы — а не проводные поля, — и развёртывание МОЖЕТ ужесточать их. Аналогичная защита на парольном пути — это максимальная длина сырого входа парольной фразы, обеспечиваемая до нормализации и Argon2id (контрольная граница 4096 байт UTF-8, MAX_PASSPHRASE_INPUT_BYTES), чтобы патологическая парольная фраза не могла вызвать отказ в обслуживании до KDF.

Действительность открытого ключа X-Wing ограничивает гибридный порог

Гибридный KEM mlkem768x25519 никогда не опускается ниже классической безопасности X25519 как порога — но этот порог задан для корректно сгенерированных ключей получателя. XWing.Encapsulate ДОЛЖНА применять к ключу получателя проверку действительности открытого ключа из закреплённой редакции X-Wing и отказываться инкапсулировать к ключу, её не прошедшему, а не трактовать неправильно сформированный ключ так, будто он несёт классическую гарантию. Производитель, пропускающий проверку, утрачивает порог для этого получателя; проверка — это предусловие, при котором порог держится.

Ограниченный размер полезной нагрузки

Слой содержимого — это сегментированный STREAM: открытый текст разбивается на фрагменты по 65536 байт, каждый из которых запечатывается под ключом содержимого с отдельным счётным nonce. 88-битный счётчик на фрагмент допускает 2^88 фрагментов, и каждый фрагмент остаётся в пределах ограничения RFC 8439 на один вызов, поэтому — в отличие от однопроходного AEAD над всем открытым текстом — нет коллизии потока ключей из-за переполнения счётчика, от которой нужно было бы защищаться, и формат не налагает криптографического потолка на размер. Поэтому максимум, который обеспечивает развёртывание, — это политика защиты от отказа в обслуживании, а не криптографическая граница: производителям и верификаторам СЛЕДУЕТ ограничивать размер полезной нагрузки по своим ресурсам и обеспечивать его инкрементально по мере записи или чтения потока, прерываясь до того, как непомерно большая нагрузка будет буферизована. Усечение ловится структурно финальным флагом на фрагмент — отсутствующий финальный фрагмент, хвостовые данные или короткий нефинальный фрагмент проваливают расшифровку, — а не проверкой размера. Эта позиция идентична на пути слотов и на парольном пути.

Гибкость выбора алгоритмов как свойство безопасности

Каждый криптографический выбор в записи Label 309 назван строкой из расширяемого реестра — хеш, AEAD, KEM, KDF, схема подписи. Это не стилистический выбор; это подложка для миграции, которая позволяет формату пережить любой отдельный алгоритм.

Если примитив ослаблен криптоанализом:

1. В соответствующий реестр добавляется идентификатор-преемник. Ничего в существующем формате не меняется — новое имя аддитивно.
2. Существующие записи остаются действительными. Верификатор продолжает распознавать старый идентификатор для исторических записей; их заявления о времени блока не теряют силы оттого, что появился более новый алгоритм. Реализация МОЖЕТ показывать запись, опирающуюся только на с тех пор ослабленный алгоритм, как имеющую меньшую степень доверия, но НЕ ДОЛЖНА стирать или отвергать её только на этом основании.
3. Новые записи публикуются под преемником. Создатель записи, которому нужна эшелонированная защита, МОЖЕТ зафиксировать хеш содержимого сразу под двумя алгоритмами из разных конструктивных семейств, чтобы взлом одного семейства не обрушил доказательную ценность записи, — хотя записи с одним алгоритмом остаются полностью соответствующими стандарту.

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

Известные пределы стандарта

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

Постоянство в блокчейне

Метаданные Cardano постоянны и реплицированы по всему миру. Опубликованную запись Label 309 нельзя удалить, отредактировать или аннулировать — эта долговечность и есть весь смысл подтверждения существования. Из этого следует ответственность в момент публикации: хеш содержимого, привязанная к стейку подпись или что угодно ещё, зафиксированное под меткой 309, остаётся в блокчейне навсегда. Label 309 намеренно опускает в записи произвольные описательные метаданные, чтобы минимизировать ончейн-след, но создатель записи ДОЛЖЕН понимать ещё до публикации, что опубликованное необратимо.

Число получателей видно

Запечатанное подтверждение существования никогда не называет своих получателей, но число слотов получателей — это длина массива, открыто видимая в блокчейне, как и семейство KEM (enc.kem) и различие «запечатано или открыто». Открытые ключи получателей с провода убраны, а слоты перемешаны, но дополнение, скрывающее число, не входит в базовый профиль. Отправитель, для которого само число получателей чувствительно, должен учитывать эту утечку метаданных на операционном уровне — например, дополняя набор слотов самостоятельно или публикуя отдельные записи.

Нет отзыва доступа для отдельного получателя

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

Нет прямой секретности для получателя — намеренно

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

Сбои пробной расшифровки не выдают ключевого материала

Получатель находит свой слот пробной расшифровкой. Внутренне — только для диагностики доверенного локального вызывающего — пути сбоя несут отдельные типизированные коды: «под моим ключом не открылся ни один слот» (WRONG_RECIPIENT_KEY), «слот открылся, но ни один ключ-кандидат не воспроизвёл slots_mac» (TAMPERED_HEADER) и «не прошёл AEAD содержимого после того, как ключ был восстановлен, а MAC проверен» (TAMPERED_CIPHERTEXT). Эти коды не несут ценности оракула: противник без подходящего закрытого ключа не открывает вообще ни одного слота, а каждый путь ошибки ДОЛЖЕН исключать нижележащие секретные байты (общий секрет, ключ шифрования ключей, ключ шифрования содержимого) из своего сообщения и цепочки причин.

Однако недоверенный внешний вызывающий ДОЛЖЕН получать ровно одну общую форму отказа независимо от того, почему расшифровка не удалась, и внешний ответ НЕ ДОЛЖЕН различать три причины по форме, ни раскрывать, какой слот совпал. Внутренние коды существуют ради локальной отладки; они НЕ ДОЛЖНЫ утекать внешнему наблюдателю через различимый ответ.

Модель времени намеренно очерчена. Верификатор МОЖЕТ вернуться на проверке отсутствия совпадения, до расшифровки содержимого, — так что неполучатель (ни один слот не открылся) может быть отделён по времени от получателя, чей слот открылся, но чей шифртекст содержимого не открывается. Это различие выдаёт лишь получателя-против-неполучателя; оно никогда не выдаёт, какой слот совпал, и никакого ключевого материала. Единообразие времени между случаем неполучателя и случаем плохого шифртекста НЕ требуется, а фиктивное открытие содержимого НЕ ДОЛЖНО предписываться — навязывание стоимости расшифровки содержимого каждому неполучателю ничего не дало бы. Гарантия постоянного времени, которая всё же держится, — это межслотовый инвариант (см. Сравнение секретов за постоянное время): в пределах прохода по одному ключу цикл идёт по всем слотам со сравнениями за постоянное время, так что наблюдатель не может узнать, какой слот, если вообще какой-либо, развернул данный ключ, — и сверх различия получатель-против-не он узнаёт лишь число слотов.

Связанные страницы

• Введение — пять инвариантов, включая независимость от издателя и автономную проверяемость.
• Подписи — строгая проверка Ed25519 и устойчивая к сбоям модель авторства.
• Sealed PoE — конверт шифрования и кратко изложенные здесь свойства приватности.
• Реестры алгоритмов — именованные идентификаторы, которые делают возможной гибкость выбора алгоритмов.
• Проверка — конвейер, политика глубины подтверждений и каталог ошибок.