Modelo de segurança

A segurança do Label 309 se apoia em uma única ideia: uma prova é algo que a parte interessada verifica por conta própria. Um verificador confia na rede pública Cardano e, no caso de alegações sobre conteúdo, nos bytes que recebe. Ele não confia em mais nada: nem em quem publica, nem em um domínio, nem em um servidor, nem no operador do gateway pelo qual aconteceu de ler a transação. Cada garantia desta página decorre dessa postura, delimita sua fronteira ou nomeia um risco residual que fica fora dela.

Esta página é o modelo de ameaças do próprio padrão: o modelo de confiança sob o qual opera um verificador em conformidade, as propriedades de privacidade de uma PoE selada não assinada, as obrigações criptográficas que toda implementação DEVE cumprir e os limites que o formato de transmissão não supera, nem poderia superar. Ela não descreve a segurança operacional de nenhuma implantação específica; descreve o que o formato garante a qualquer pessoa que o implemente corretamente.

O modelo de confiança

A parte interessada que verifica uma prova Label 309 faz uma pergunta restrita: esses bytes existiam até o horário deste bloco e esse veredito depende do bom comportamento de mais alguém além da própria Cardano? O padrão foi construído para que a resposta à segunda metade seja sempre "não". Não há intermediário controlado por quem emite em nenhuma etapa: o gateway de cadeia e o gateway de armazenamento que um verificador consulta são fontes de dados não confiáveis, verificadas criptograficamente onde é possível e cruzadas quanto à inclusão e à finalidade.

No que um verificador confia:

• Na rede pública Cardano. A transação, seus metadados sob o rótulo 309 e o horário de seu bloco são fatos replicados em todos os nós da Cardano. Um verificador os lê por meio de um gateway de sua escolha e pode conferi-los em vários.
• Nos bytes do conteúdo, ao verificar uma alegação sobre conteúdo. Um resumo no registro compromete-se com uma sequência específica de bytes. Um verificador que possui esses bytes recalcula o hash e compara; ele não aceita a palavra de ninguém de que os bytes conferem.

No que um verificador não confia:

• Em quem publica. O Label 309 não tem um campo issuer. Qualquer carteira pode publicar qualquer registro; a validade do registro independe de quem o submeteu. Um verificador nunca pergunta "esse emissor é confiável?": a pergunta não tem lugar no modelo. Veja a invariante de independência do emissor em Introdução.
• Em um servidor ou domínio. Nenhuma etapa da verificação entra em contato com um serviço operado por quem publica. Não há registro canônico a consultar, nem endpoint de status a sondar, nem autoridade de identidade para resolver uma chave.
• No operador de um gateway. Os gateways de Cardano, Arweave e IPFS pelos quais um verificador lê são intercambiáveis e têm seu conteúdo conferido (abaixo). Um gateway é um meio de transporte, não uma raiz de confiança.

Por que gateways não são uma raiz de confiança

Um verificador pode ler a mesma transação por meio de qualquer gateway de Cardano e ler o mesmo conteúdo por meio de qualquer gateway de Arweave ou IPFS. Não se confia em nenhum deles para devolver dados honestos, porque aquilo que devolvem é verificável de forma independente:

• Um gateway não consegue forjar um registro que carregue uma assinatura válida: ele não possui a chave privada de quem assina, e o verificador recalcula os bytes assinados e os confere por conta própria. Veja Assinaturas.
• Um gateway não consegue substituir o conteúdo sob uma URI endereçada pelo conteúdo sem que isso seja detectado: um CID ipfs:// é um multihash que o verificador recalcula a partir dos bytes obtidos, e um id de transação ar:// compromete-se com os dados sob o consenso da Arweave. Em um item em conformidade, o mapa hashes na blockchain é um segundo vínculo, independente, com o texto claro, recalculado no momento da obtenção.
• Um gateway que retém uma transação ou informa de forma incorreta quão profundamente ela está enterrada configura uma negação de serviço, não uma falsificação. Um verificador que lê por meio de mais de um gateway e aborta diante de qualquer divergência transforma "um gateway desonesto" em "conluio entre todos os gateways que ele escolheu", algo que está sob seu controle.

A profundidade do bloco, ou seja, quantas confirmações um verificador exige antes de tratar um registro como consolidado, é uma política do verificador, não um valor que o Label 309 imponha. O padrão não fixa nenhuma profundidade numérica; a parte interessada define um limiar de acordo com sua própria tolerância a risco. Veja Verificação.

Propriedades de privacidade da PoE selada

Uma PoE selada mantém um texto claro confidencial enquanto ainda ancora seu carimbo de tempo. Além da confidencialidade, a construção é projetada para que a rede revele o mínimo possível sobre a mensagem e nada sobre seu público. Essas são garantias do formato de transmissão: valem para qualquer implementação correta, porque são propriedades dos bytes, não de nenhuma implantação.

Anonimato do remetente em uma PoE selada não assinada

Uma PoE selada não assinada, ou seja, um registro que carrega enc e nenhum sigs, NÃO DEVE revelar a identidade do remetente na blockchain. Os bytes que ela transmite DEVEM ser independentes das chaves de longo prazo do remetente.

Isso se sustenta estruturalmente:

• Nenhuma chave de quem assina nos bytes transmitidos. A chave de identidade de um remetente chega à rede apenas por meio de uma entrada sigs. Um registro sem sigs não carrega nenhum byte do lado de quem assina. A autoria é opcional; o anonimato é o padrão. As chaves X25519 e Ed25519 de longo prazo do remetente nunca aparecem em um registro não assinado.
• Encapsulamento novo por slot. Cada slot de destinatário carrega material de KEM específico do registro e do slot, gerado do zero no momento do selamento — a chave pública efêmera X25519 em slot.epk no caminho x25519, ou o texto cifrado X-Wing em slot.kem_ct no caminho mlkem768x25519. Ele não tem relação com a chave de longo prazo do remetente e não revela nada que vincule registros a um autor comum.
• Slots embaralhados. O arranjo de slots é embaralhado com um CSPRNG antes da publicação, de modo que a ordem das posições ("destinatário principal primeiro") não transmite nenhum sinal.

Quem mais tarde assina um registro revela sua chave de identidade apenas naquele registro; ela não aparece em nenhum registro não assinado anterior, e nenhuma operação relaciona o material de KEM por slot dos registros anteriores de volta ao autor. As chaves de identidade X25519 e Ed25519 derivam da semente mestra por meio de strings de contexto HKDF diferentes, e uma chave pública Ed25519 não pode derivar nem coincidir com uma chave pública X25519, de modo que assinar um registro nunca vincula os não assinados. Optar pela autoria é um ato voltado para o futuro, não uma desanonimização retroativa.

Esta invariante cobre apenas os bytes do registro label-309. O endereço Cardano que paga a taxa nas entradas da transação, a identidade de nível de rede de quem produz, vista por um gateway, e quaisquer metadados no blob de texto cifrado fora da blockchain estão fora do formato de transmissão. O Label 309 reside nos metadados, não nas entradas da transação, e não pode se defender contra a correlação de quem paga a taxa. Quem produz e precisa do anonimato de quem paga a taxa deve tratar disso na camada de construção da transação.

Indistinguibilidade entre destinatários

Um registro selado nunca nomeia seus destinatários. Um destinatário só reconhece uma mensagem como sua ao decifrar com sucesso um slot por tentativa; não há campo de endereçamento a ler. Daí decorrem duas garantias distintas, que não devem ser confundidas.

A primeira vale para ambos os KEMs e para qualquer observador:

• Os destinatários não conseguem ver uns aos outros. Cada slot é uma chave envelopada de forma independente. Um destinatário que abre o próprio slot não deduz nada sobre nenhum outro slot e não consegue dizer quem mais foi endereçado.
• Nenhuma chave pública de destinatário nos bytes transmitidos. Apenas o encapsulamento por slot (epk ou kem_ct) e a chave envelopada aparecem. Um observador sem chaves candidatas não consegue enumerar os destinatários — fica sabendo apenas a contagem de slots, a família de KEM (enc.kem) e a distinção entre selado e aberto.

A segunda — o anonimato do destinatário diante de um adversário que já detém um conjunto de chaves públicas candidatas de destinatários e quer testar se um slot é endereçado a uma delas — é uma propriedade mais forte e específica do KEM, e o padrão a afirma apenas para o caminho clássico:

• x25519 é privado quanto à chave. O epk de cada slot é uma chave pública efêmera nova, estatisticamente independente da chave do destinatário. Só com epk e wrap, um adversário de posse de chaves não consegue decidir qual candidata (se alguma) um slot tem como alvo sem a chave privada correspondente.
• mlkem768x25519 não a afirma. O anonimato do destinatário diante de um adversário de posse de chaves é uma propriedade separada, não implicada pela segurança IND-CCA do KEM híbrido, e não é afirmada para o caminho X-Wing a menos que e até que seja justificada de forma independente para o X-Wing. Uma implantação cujo modelo de ameaças exige anonimato do destinatário diante de um adversário de posse de chaves NÃO DEVE apoiar-se no caminho híbrido para essa propriedade. Os vazamentos honestos acima — contagem de slots, família de KEM, selado versus aberto — são idênticos para ambos os KEMs; nada além disso sobre os destinatários é exposto em qualquer dos caminhos.

Vínculo com o texto claro

O resumo na blockchain compromete-se com o texto claro, não com o texto cifrado. Um destinatário que decifra uma PoE selada recalcula o hash do texto claro e o compara com o mapa hashes na blockchain. Isso significa que uma camada de armazenamento que entregue um texto cifrado adulterado é flagrada após a decifragem, independentemente do modelo de integridade da própria URI: a alegação de carimbo de tempo é uma alegação sobre o texto claro com o qual o remetente se comprometeu, e nada que o gateway faça consegue satisfazê-la com bytes diferentes.

Independência de retransmissões

As assinaturas de um registro são fixadas no momento em que sua transação é submetida. A rede não tem noção de um "conjunto estendido de signatários" que se acumula ao longo de transações.

Retransmitir um corpo de registro idêntico em uma transação separada, com um conjunto sigs diferente, cria um registro separado e independente, com seu próprio horário de bloco, nunca uma extensão do original.

Quem deseja endossar um registro já publicado publica seu próprio registro, referenciando o mesmo conteúdo, ou apontando para a transação anterior por meio de supersedes, assinado com sua chave. Não se acrescenta uma testemunha ao registro de outra pessoa. Por consequência, um atacante que copia os bytes de um registro assinado para uma nova transação não se torna cossignatário do original: ele produz uma alegação posterior e duplicada, com qualquer sigs que tenha escolhido, e o horário de bloco anterior do original permanece o registro canônico de existência. Verificadores e indexadores NÃO DEVEM fundir duas transações com corpos de registro idênticos em uma única visão de "signatários mesclados"; fazê-lo falsificaria a semântica de horário de bloco por registro da qual os consumidores subsequentes dependem.

Regras normativas para implementações

As regras a seguir são normativas em termos de segurança para qualquer implementação em conformidade, independentemente da linguagem ou plataforma. As palavras-chave da RFC 2119 / RFC 8174 são usadas em seu sentido normativo.

Sem criptografia inédita

O Label 309 admite deliberadamente apenas primitivas bem analisadas, cada uma nomeada nos registros de identificadores de algoritmos e implementada por uma biblioteca auditada. Uma implementação NÃO DEVE introduzir uma cifra simétrica, um KDF, uma construção de assinatura ou uma stanza de envelopamento de chave personalizados. O formato de transmissão é uma composição de partes padronizadas justamente para que sua segurança se reduza à segurança dessas partes.

Apenas criptografia autenticada

Toda criptografia simétrica no Label 309, tanto a camada de conteúdo quanto o envelopamento de chave por slot, é AEAD. Não há nenhum modo de cifra não autenticado em lugar algum do formato. Quem decifra e tem a verificação da tag AEAD falhada DEVE expor um erro estruturado com um discriminador de código estável e NÃO DEVE prosseguir para devolver bytes não autenticados. O dado autenticado adicional faz parte do cálculo da tag, de modo que um AAD errado falha de maneira idêntica a uma chave errada: não há estado de sucesso parcial a sondar.

Comparação de segredos em tempo constante

Um laço de comparação cujo tempo de execução depende de bytes secretos é um oráculo. Toda verificação de igualdade sobre um segredo ou sobre uma tag MAC/AEAD DEVE ser em tempo constante:

• O MAC do conjunto de slots e qualquer tag HMAC: um vazamento de tempo por byte em um MAC de 32 bytes pode, sob repetição adversária, recuperar a tag.
• A verificação da tag AEAD: o decrypt da biblioteca subjacente já devolve falha sem revelar qual byte não conferiu; as implementações NÃO DEVEM reimplementar essa verificação.
• A verificação de assinatura: use o verify da biblioteca, nunca uma equação feita à mão.

Um == / === cru sobre arranjos de bytes que toque qualquer uma dessas superfícies é um defeito. Encaminhar toda comparação desse tipo por meio de um único auxiliar tipado torna a propriedade auditável.

A disciplina de tempo constante se estende à forma do laço de tentativa de decifragem, não apenas às comparações individuais. Para preservar a propriedade de destinatário oculto, um verificador de destinatário DEVE processar todos os slots dentro da passada de uma única chave privada — um número constante de operações de slot por chave, sem interrupção antecipada na primeira coincidência — para que um observador de nível de rede com acesso à temporização não consiga inferir qual índice de slot uma chave desenvolveu, nem se alguma o fez. A chave candidata é selecionada em tempo constante. A validade do compartilhamento X25519 é capturada por um bit independente do segredo, kem_ok = NOT constantTimeEqual(shared, 0^32), calculado com uma comparação em tempo constante em vez de um desvio antecipado; a KEK é então uma seleção em tempo constante entre a KEK real e uma KEK fictícia derivada de um segredo compartilhado todo de zeros sob o mesmo salt e o mesmo info, e kem_ok é incorporado à aceitação do slot (ok = kem_ok AND open_ok AND mac_ok), de modo que um slot com ECDH inválido nunca possa ser aceito enquanto o laço ainda realiza trabalho idêntico. O arranjo de slots é publicado em ordem embaralhada por CSPRNG, de modo que a posição em trânsito já não carrega nenhum sinal de "destinatário principal primeiro"; combinada com a passada em tempo constante, um observador fica sabendo apenas a contagem de slots. Um destinatário que detém várias chaves privadas (por exemplo, chaves arquivadas ao longo de uma rotação de identidade) itera chave × slot e PODE curto-circuitar entre chaves — isso vaza apenas o sinal fraco de "qual chave coincidiu" — mas DEVE permanecer em tempo constante ao longo dos slots de qualquer chave isolada, re-derivando a metade do salt da KEK correspondente à chave do destinatário por chave, já que ambos os KEMs vinculam o salt à codificação de transmissão canônica dessa chave (exatamente a chave pública X25519 de 32 bytes, ou exatamente os 1216 bytes da chave pública X-Wing fixada — nunca uma recodificação não canônica).

Verificação estrita de Ed25519

As assinaturas Label 309 DEVEM ser verificadas no modo estrito (canônico). Um verificador relaxado, com cofator, aceita certas assinaturas maleáveis ou de chave de baixa ordem que um verificador estrito rejeita, o que permitiria que duas implementações em conformidade discordassem sobre o mesmo registro, quebrando a propriedade de veredito único da qual todo o padrão depende. O corpus de conformidade entre linguagens fixa um vetor de teste de baixa ordem exatamente para flagrar um verificador que tenha escorregado para o modo relaxado. Veja Assinaturas.

Nunca registrar material secreto

Bytes de seed, chaves privadas derivadas, chaves de criptografia de chaves, chaves de criptografia de conteúdo, material derivado de frase secreta e texto claro decifrado NÃO DEVEM chegar aos logs em nenhum nível. A redação baseada em caminhos na configuração de um logger é necessária, mas não suficiente por si só: um valor aninhado mais fundo do que o glob de redação alcança pode escapar, de modo que as implementações DEVEM também tratar todo valor tipado como bytes (Uint8Array, bytes e afins) como opaco e redigido incondicionalmente, mesmo para valores públicos do protocolo, como um nonce. O segredo mais barato de proteger é aquele que nunca entra em uma linha de log.

Garantias da construção da PoE selada

Três propriedades adicionais são específicas da construção da PoE selada. Elas são normativas em termos de segurança para qualquer implementação que produza ou abra um registro selado.

O MAC do conjunto de slots é um compromisso de ~128 bits

O MAC do conjunto de slots é o que faz de uma chave de conteúdo recuperada um compromisso com o conjunto de slots que o destinatário coincidiu: um remetente malicioso não consegue construir dois conjuntos de slots distintos que um único destinatário aceite como "seus". A propriedade exigida é o compromisso restrito de chave para a chave de conteúdo do envelope, no sentido da RFC 9771 — a chave recuperada se vincula a uma única transcrição de slots — e não um AEAD comprometedor pleno sobre entradas arbitrárias. O destinatário deriva uma chave de um slot e então exige que essa mesma chave reproduza slots_mac sobre o hash da transcrição de slots antes de tratar o slot como próprio. Concretamente, o compromisso repousa sobre a resistência a colisões multi-chave de

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

para CEKs e transcrições escolhidas adversarialmente. Como o adversário controla tanto a CEK quanto a transcrição, o limite pertinente é o limite de colisão genérica (aniversário) sobre a saída HMAC de 256 bits: encontrar dois pares (CEK, transcript) que produzam o mesmo slots_mac é uma busca de ~128 bits, não o nível de segunda pré-imagem de 256 bits. Uma margem de colisão genérica de 128 bits é o nível de segurança em que este compromisso se apoia, e é adequada ao modelo de ameaças.

Reduzir antecipadamente a transcrição por hash a um slots_hash de 32 bytes antes do HMAC não enfraquece isso: uma colisão de slots_mac implica ou uma colisão de slots_hash (uma colisão de SHA-256) ou uma colisão do HMAC com chave sobre slots_hash iguais, ambas no nível de ~128 bits. A evidência de adulteração da própria transcrição herda o limite de colisão 2^128 do SHA-256: qualquer alteração de um campo de cabeçalho comprometido ou de um byte de slot altera slots_hash, e forjar um slots_hash inalterado sobre uma transcrição diferente é exatamente aquela busca de colisão de ~128 bits. Uma consequência direta é que o envoltório por slot não precisa ser um AEAD comprometedor: o compromisso é fornecido por slots_mac, não pelo envoltório, de modo que um envoltório não comprometedor (o ChaCha20-Poly1305 padrão) é sólido aqui.

A segurança do envoltório de nonce zero repousa na unicidade da chave por slot

Cada slot envolve a chave de conteúdo sob uma chave de criptografia de chave por slot com ChaCha20-Poly1305 a um nonce zero. Um nonce zero só é seguro porque a chave de criptografia de chave é por slot e usada para exatamente um envoltório: cada slot sorteia aleatoriedade de KEM nova, de modo que a chave de envoltório é única por slot com probabilidade de colisão desprezível. A condição de segurança é exatamente a unicidade da chave por slot, e um produtor NÃO DEVE introduzir nada que possa repetir um par (key, nonce) — uma falha de CSPRNG que repita a aleatoriedade de KEM, um encapsulamento determinístico ou colidente, o reúso de um slot entre registros, o cache de uma chave derivada por (recipient, ephemeral), ou a deduplicação de duas aparições do mesmo destinatário em um único slot.

Isso se divide com clareza em uma fatia verificável pelo verificador e uma obrigação exclusiva do produtor:

• As duplicatas dentro do registro são rejeitadas pelo verificador. Um verificador DEVE exigir que o material de encapsulamento seja distinto dentro de um mesmo slots[] — todos os valores de epk distintos no caminho x25519, todos os valores de kem_ct distintos no caminho mlkem768x25519. Uma duplicata é rejeitada antes que qualquer primitiva KEM ou AEAD seja executada, com o código tipado ENC_SLOTS_DUPLICATE_KEM_MATERIAL. O corpus de conformidade exercita isso com um registro que carrega dois slots compartilhando um epk (ou kem_ct) e exige essa rejeição. Essa rejeição dispara apenas em um epk / kem_ct repetido; ela não proíbe selar para o mesmo destinatário duas vezes, já que a duplicação honesta ainda sorteia aleatoriedade de KEM por slot fresca para cada aparição (veja a regra de múltiplos slots correspondentes abaixo).
• O reúso entre registros e entre chaves é uma obrigação do produtor. Nenhum verificador consegue detectar que um produtor reusou material de KEM entre dois registros ou destinatários diferentes; isso fica fora dos bytes de qualquer registro isolado e permanece responsabilidade do produtor. Caso uma revisão futura permita o reúso de chave, o nonce zero teria de ser substituído por um nonce novo na mesma mudança.

Múltiplos slots correspondentes: o preenchimento é permitido, um conflito de CEK não

A chave privada de um destinatário PODE legitimamente corresponder a mais de um slot. Selar a mesma chave de conteúdo para o mesmo destinatário em vários slots — cada um com efêmeros por slot frescos — é uma técnica de preenchimento e de privacidade válida, elevando a contagem visível de slots sem revelar que dois dos slots compartilham um destinatário. Isso é distinto da rejeição de encapsulamento duplicado dentro do registro acima: a duplicação honesta sorteia aleatoriedade de KEM fresca, de modo que seus epk / kem_ct diferem e ela nunca dispara ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Um verificador, portanto, DEVE selecionar a chave de conteúdo do primeiro slot correspondente e NÃO DEVE rejeitar apenas porque mais de um slot correspondeu.

A única anomalia que um verificador DEVE rejeitar são dois slots correspondentes que recuperam chaves de conteúdo diferentes, comparadas em tempo constante. O laço de tentativa de decifragem carrega um bit cek_conflict ao longo de todos os slots e expõe a única falha genérica se qualquer correspondência posterior recuperar uma chave que difira da já selecionada. Isso é defesa em profundidade: sob a propriedade de compromisso acima, uma correspondência com chave distinta já é inviável — é exatamente a colisão multi-chave que essa propriedade exclui — de modo que a verificação falha de forma fechada contra uma implementação quebrada ou um enfraquecimento futuro da suposição. O caso negativo de chave distinta não é construível como vetor de bytes (construir um seria a própria colisão de compromisso), de modo que a propriedade é fixada por testes comportamentais em nível de implementação, e não por uma fixture, ao lado de uma fixture positiva para a duplicação legítima de destinatário.

Limites de recursos do parser antes de qualquer primitiva

Um verificador DEVE limitar o uso de recursos do parser antes de invocar qualquer primitiva KEM ou AEAD, de modo que um envelope superdimensionado não possa impor trabalho antes de ser rejeitado. Os limites de referência são MAX_SLOTS = 1024 slots e 65536 bytes para o envelope enc decodificado — ambos muito acima do teto de ~16 KiB de metadados de transação da Cardano que restringe qualquer registro honesto, de modo que um registro que exceda qualquer um dos limites é malformado. Uma contagem excessiva é rejeitada com ENC_SLOTS_TOO_MANY, um envelope grande demais com ENC_ENVELOPE_TOO_LARGE. Esses são constantes impostas pelo verificador e fixadas pela implantação — não campos de transmissão — e uma implantação PODE restringi-los. A barreira análoga no caminho da frase secreta é um comprimento máximo de entrada bruta da frase secreta imposto antes da normalização e do Argon2id (limite de referência 4096 bytes UTF-8, MAX_PASSPHRASE_INPUT_BYTES), de modo que uma frase secreta patológica não possa provocar uma negação de serviço pré-KDF.

A validade da chave pública X-Wing delimita o piso híbrido

O KEM híbrido mlkem768x25519 nunca cai abaixo da segurança clássica do X25519 como um piso — mas esse piso é restrito a chaves de destinatário geradas validamente. XWing.Encapsulate DEVE aplicar a verificação de validade de chave pública da revisão fixada do X-Wing à chave do destinatário e recusar encapsular para uma chave que falhe nela, em vez de tratar uma chave malformada como se ela carregasse a garantia clássica. Um produtor que pule a verificação abdica do piso para aquele destinatário; a verificação é a precondição sob a qual o piso vale.

Tamanho de carga útil limitado

A camada de conteúdo é um STREAM segmentado: o texto claro é dividido em blocos de 65536 bytes, cada um selado sob a chave de conteúdo com um nonce de contador distinto. O contador de 88 bits por bloco admite 2^88 blocos, e cada bloco permanece bem dentro do limite de invocação única do RFC 8439, de modo que — ao contrário de um AEAD de passada única sobre todo o texto claro — não há colisão de fluxo de chaves por estouro de contador contra a qual se proteger e o formato não impõe nenhum teto criptográfico de carga útil. O máximo que uma implantação impõe é, portanto, uma política de negação de serviço, não um limite criptográfico: produtores e verificadores DEVERIAM limitar o tamanho da carga útil ao que cabe em seus recursos e impô-lo de forma incremental à medida que o fluxo é escrito ou lido, abortando antes que uma carga útil superdimensionada seja armazenada em buffer. O truncamento é detectado estruturalmente pelo sinalizador de bloco final por bloco — um bloco final ausente, dados sobressalentes ou um bloco não final curto fazem a decifragem falhar —, e não por uma verificação de tamanho. A postura é idêntica no caminho de slots e no caminho de frase secreta.

Agilidade de algoritmos como propriedade de segurança

Toda escolha criptográfica em um registro Label 309 é nomeada por uma string de um registro de identificadores extensível: o hash, o AEAD, o KEM, o KDF, o esquema de assinatura. Isso não é uma escolha estilística; é o substrato de migração que permite ao formato sobreviver a qualquer algoritmo isolado.

Se uma primitiva for enfraquecida por criptoanálise:

1. O registro pertinente ganha um identificador sucessor. Nada no formato existente muda: o novo nome é aditivo.
2. Os registros existentes continuam válidos. Um verificador continua reconhecendo o identificador antigo para registros históricos; suas alegações de horário de bloco não evaporam porque um algoritmo mais novo existe. Uma implementação PODE apresentar um registro que depende apenas de um algoritmo desde então enfraquecido como de menor garantia, mas NÃO DEVE apagá-lo ou rejeitá-lo apenas por esse motivo.
3. Os novos registros são publicados sob o sucessor. Quem produz e quer defesa em profundidade PODE comprometer um hash de conteúdo sob dois algoritmos de famílias de projeto distintas, de modo que a quebra de uma única família não derrube o valor probatório do registro, embora registros de algoritmo único permaneçam plenamente em conformidade.

Como os identificadores são strings e os registros são abertos, migrar para hashes, KEMs ou assinaturas pós-quânticos é uma mudança aditiva de registro, nunca uma revisão de formato que quebre a compatibilidade. O KEM híbrido pós-quântico já presente no registro é uma instância dessa propriedade em ação, não um caso especial acoplado por fora.

Limites conhecidos do padrão

Estes não são defeitos a serem corrigidos em uma revisão posterior; são propriedades inerentes a ancorar provas em um livro-razão público e permanente e à criptografia de chave pública para chaves de longo prazo. Um modelo de segurança honesto os nomeia.

Permanência na blockchain

Os metadados da Cardano são permanentes e replicados globalmente. Um registro Label 309 publicado não pode ser apagado, redigido ou invalidado: essa durabilidade é todo o propósito da prova de existência. A consequência é uma responsabilidade no momento da publicação: um hash de conteúdo, uma assinatura vinculada a stake ou qualquer outra coisa comprometida sob o rótulo 309 fica na blockchain para sempre. O Label 309 omite deliberadamente metadados descritivos em texto livre do registro para manter mínima a pegada na blockchain, mas quem produz DEVE entender que aquilo que publica é irrevogável antes de publicar.

A contagem de destinatários é visível

Uma PoE selada nunca nomeia seus destinatários, mas o número de slots de destinatário é o comprimento do arranjo, claramente visível na blockchain — assim como a família de KEM (enc.kem) e a distinção entre selado e aberto. As chaves públicas dos destinatários ficam fora dos bytes transmitidos e os slots são embaralhados, mas o preenchimento que oculta a contagem não faz parte da base. Um remetente para quem a própria contagem de destinatários é sensível precisa tratar desse vazamento de metadados operacionalmente, por exemplo preenchendo ele mesmo o conjunto de slots ou publicando registros separados.

Sem revogação por destinatário

Não há primitiva na blockchain para revogar o acesso de um único destinatário a uma PoE selada já publicada. Uma vez que um registro é criptografado para uma chave pública e ancorado, esse vínculo é permanente. Esta é uma propriedade inerente à criptografia de chave pública para uma chave de longo prazo, não uma lacuna do formato. Uma chave tida como comprometida é tratada daí em diante, endereçando novos registros a uma chave nova e, opcionalmente, publicando um registro substituto como um aviso de "que o comprador se acautele", nunca voltando atrás para alterar o que já está na blockchain.

Sem sigilo futuro para o destinatário, por projeto

Quem detém a chave privada de um destinatário pode decifrar toda PoE selada já endereçada a ela, para sempre. O texto cifrado fora da blockchain é permanente e não há primitiva de revogação, então um registro selado é privado para o mundo, mas não para seu destinatário. Esse é o comportamento esperado ao criptografar para uma chave pública de longo prazo. Um remetente que precisa limitar o alcance futuro de um destinatário deve criptografar para uma chave de destinatário de vida curta, em vez de uma chave de identidade de longo prazo, uma escolha do lado do remetente que o formato permite, mas não exige.

Falhas de decifragem por tentativa não vazam material de chaves

Um destinatário descobre seu slot por decifragem por tentativa. Internamente — apenas para o diagnóstico de um chamador local confiável — os caminhos de falha carregam códigos tipados distintos: "nenhum slot abriu sob minha chave" (WRONG_RECIPIENT_KEY), "um slot abriu, mas nenhuma chave candidata reproduziu slots_mac" (TAMPERED_HEADER) e "o AEAD do conteúdo falhou depois que uma chave foi recuperada e o MAC foi verificado" (TAMPERED_CIPHERTEXT). Esses códigos não têm valor de oráculo: um adversário sem uma chave privada correspondente não abre slot algum, e todo caminho de erro DEVE excluir de sua mensagem e de sua cadeia de causas os bytes secretos subjacentes (segredo compartilhado, chave de criptografia de chaves, chave de criptografia de conteúdo).

Um chamador externo não confiável, porém, DEVE receber exatamente uma forma de falha genérica, qualquer que tenha sido o motivo da falha de decifragem, e a resposta externa NÃO DEVE distinguir as três causas pela forma, nem revelar qual slot correspondeu. Os códigos internos existem para a depuração local; eles NÃO DEVEM vazar para um observador externo por meio de uma resposta distinguível.

O modelo de temporização é deliberadamente delimitado. Um verificador PODE retornar na verificação de não correspondência, antes da decifragem do conteúdo — de modo que um não destinatário (nenhum slot abriu) possa ser cronometrado separadamente de um destinatário cujo slot abriu mas cujo texto cifrado de conteúdo falha ao abrir. Essa distinção revela apenas destinatário versus não destinatário; ela nunca revela qual slot correspondeu, nem qualquer material de chave. Uma temporização uniforme entre o caso do não destinatário e o caso do texto cifrado inválido NÃO é exigida, e uma abertura de conteúdo fictícia NÃO DEVE ser obrigatória — forçar o custo da decifragem de conteúdo sobre todo não destinatário não compraria nada. A garantia de tempo constante que de fato vale é a invariante entre slots (veja Comparação de segredos em tempo constante): dentro da passada de uma única chave, o laço percorre todos os slots com comparações em tempo constante, de modo que um observador não consiga saber qual slot, se algum, uma dada chave desembrulha — e, além da distinção destinatário-versus-não, fica sabendo apenas a contagem de slots.

Páginas relacionadas

• Introdução — as cinco invariantes, incluindo a independência do emissor e a verificabilidade independente.
• Assinaturas — a verificação estrita de Ed25519 e o modelo de autoria com falha tolerante.
• PoE selada — o envelope de criptografia e as propriedades de privacidade resumidas aqui.
• Registros de identificadores de algoritmos — os identificadores nomeados que tornam possível a agilidade de algoritmos.
• Verificação — o pipeline, a política de profundidade de confirmação e o catálogo de erros.