Modello di sicurezza

La sicurezza di Label 309 poggia su un'idea sola: una prova è qualcosa che la parte che vi fa affidamento controlla da sé. Un verificatore si fida della catena pubblica Cardano e, per le rivendicazioni sul contenuto, dei byte che gli vengono consegnati. Non si fida di nient'altro: non del pubblicante, non di un dominio, non di un server, non di chi gestisce il gateway attraverso cui ha letto la transazione. Ogni garanzia di questa pagina deriva da questa impostazione, ne segna il confine o nomina un rischio residuo che cade al di fuori.

Questa pagina è il modello delle minacce dello standard stesso: il modello di fiducia entro cui opera un verificatore conforme, le proprietà di riservatezza di una PoE sigillata non firmata, gli obblighi crittografici che ogni implementazione DEVE rispettare e i limiti che il formato wire non supera, e non può superare. Non descrive la sicurezza operativa di un particolare deployment; descrive ciò che il formato garantisce a chiunque lo implementi correttamente.

Il modello di fiducia

Una parte che fa affidamento sul controllo di una prova Label 309 si pone una domanda circoscritta: questi byte esistevano all'orario di questo blocco o prima di esso, e questo verdetto dipende dal comportamento corretto di qualcuno oltre a Cardano? Lo standard è costruito in modo che la risposta alla seconda parte sia sempre "no". Non esiste alcun intermediario controllato dall'emittente in nessun passaggio: il gateway della catena e lo storage gateway che un verificatore consulta sono fonti di dati non fidate, verificate crittograficamente dove possibile e incrociate per inclusione e finalità.

Ciò di cui un verificatore si fida:

• La catena pubblica Cardano. La transazione, i suoi metadati sotto label 309 e il suo block time (l'orario del blocco) sono fatti replicati su ogni nodo Cardano. Un verificatore li legge attraverso un gateway di propria scelta e può incrociarne più di uno.
• I byte del contenuto, quando controlla una rivendicazione sul contenuto. Un digest nel record si vincola a una specifica sequenza di byte. Un verificatore in possesso di quei byte ricalcola l'hash e lo confronta; non si fida sulla parola di nessuno che i byte corrispondano.

Ciò di cui un verificatore non si fida:

• Il pubblicante. Label 309 non ha un campo issuer. Qualsiasi wallet può pubblicare qualsiasi record; la validità del record è indipendente da chi lo ha inviato. Un verificatore non si chiede mai "questo pubblicante è affidabile?": la domanda non ha posto nel modello. Vedi l'invariante "indipendente dall'emittente" nell'Introduzione.
• Un server o un dominio. Nessun passaggio della verifica contatta un servizio gestito dal pubblicante. Non c'è alcun registro canonico da consultare, alcun endpoint di stato da interrogare, alcuna autorità di identità presso cui risolvere una chiave.
• Chi gestisce un gateway. I gateway Cardano, Arweave e IPFS attraverso cui un verificatore legge sono intercambiabili e i loro dati sono verificati sul contenuto (più sotto). Un gateway è un mezzo di trasporto, non una radice di fiducia.

Perché i gateway non sono una radice di fiducia

Un verificatore può leggere la stessa transazione attraverso qualsiasi gateway Cardano e lo stesso contenuto attraverso qualsiasi gateway Arweave o IPFS. Nessuno di questi gode di fiducia nel restituire dati onesti, perché ciò che restituiscono è controllabile in modo indipendente:

• Un gateway non può falsificare un record che porta una firma valida: non detiene la chiave privata del firmatario, e il verificatore ricalcola i byte firmati e li controlla da sé. Vedi Firme.
• Un gateway non può sostituire il contenuto sotto un URI indirizzato al contenuto senza che venga rilevato: un CID ipfs:// è un multihash che il verificatore ricalcola dai byte scaricati, e un id di transazione ar:// si vincola ai dati sotto il consenso Arweave. Su un elemento conforme, la mappa hashes on-chain (sulla blockchain) è un secondo vincolo, indipendente, al testo in chiaro, ricalcolato al momento del fetch.
• Un gateway che trattiene una transazione o riporta in modo errato quanto in profondità essa è sepolta produce una forma di denial-of-service, non una forma di falsificazione. Un verificatore che legge attraverso più di un gateway e si interrompe in caso di disaccordo trasforma "un gateway disonesto" in "una collusione tra tutti i gateway scelti", e quella scelta la controlla lui.

La profondità di blocco, ovvero quante conferme un verificatore pretende prima di considerare un record consolidato, è una politica del verificatore, non un valore imposto da Label 309. Lo standard non fissa alcuna profondità numerica; la parte che fa affidamento imposta una soglia in base alla propria tolleranza al rischio. Vedi Verifica.

Proprietà di riservatezza della PoE sigillata

Una PoE sigillata mantiene riservato un testo in chiaro pur ancorandone il timestamp. Oltre alla riservatezza, il costrutto è progettato in modo che la catena riveli il meno possibile sul messaggio e nulla sui suoi destinatari. Sono garanzie del formato wire: valgono per qualsiasi implementazione corretta, perché sono proprietà dei byte, non di un particolare deployment.

Anonimato del mittente nella PoE sigillata non firmata

Una PoE sigillata non firmata, ovvero un record che porta enc e nessun sigs, NON DEVE rivelare l'identità del mittente sulla catena. I suoi byte sul wire DEVONO essere indipendenti dalle chiavi a lungo termine del mittente.

Questo vale a livello strutturale:

• Nessuna chiave del firmatario sul wire. La chiave d'identità di un mittente raggiunge la catena solo attraverso una voce sigs. Un record senza sigs non porta alcun byte lato firmatario. La paternità è opzionale; l'anonimato è l'impostazione predefinita. Le chiavi a lungo termine X25519 ed Ed25519 del mittente non compaiono mai in un record non firmato.
• Incapsulamento fresco per ogni slot. Ogni slot di destinatario porta materiale KEM specifico per quel record e per quello slot, generato fresco al momento della sigillatura, ovvero la chiave pubblica effimera X25519 in slot.epk sul percorso x25519, oppure il testo cifrato X-Wing in slot.kem_ct sul percorso mlkem768x25519. Non ha alcuna relazione con la chiave a lungo termine del mittente e non rivela nulla che colleghi i record a un autore comune.
• Slot mescolati. L'array degli slot viene mescolato con un CSPRNG prima della pubblicazione, così l'ordine posizionale ("prima il destinatario principale") non veicola alcun segnale.

Chi in seguito firma un record rivela la propria chiave d'identità solo in quel record; essa non compare in alcun record non firmato precedente, e nessuna operazione riconduce all'autore il materiale KEM per slot dei record precedenti. Le chiavi d'identità X25519 ed Ed25519 si derivano dal seed principale tramite stringhe di contesto HKDF diverse, e una chiave pubblica Ed25519 non può derivare né coincidere con una chiave pubblica X25519, perciò firmare un record non collega mai quelli non firmati. Scegliere di attribuirsi la paternità è un atto rivolto in avanti, non una deanonimizzazione retroattiva.

Questo invariante copre solo i byte del record label-309. L'indirizzo Cardano che paga la commissione negli input della transazione, l'identità a livello di rete del produttore così come la vede un gateway e qualsiasi metadato nel blob di testo cifrato off-chain sono al di fuori del formato wire: Label 309 vive nei metadati, non negli input della transazione, e non può difendere dalla correlazione tramite chi paga la commissione. Un produttore che ha bisogno dell'anonimato di chi paga la commissione deve affrontare il problema al livello di costruzione della transazione.

Non collegabilità dei destinatari

Un record sigillato non nomina mai i propri destinatari. Un destinatario riconosce un messaggio come proprio solo decifrando con successo uno slot in via di prova; non c'è alcun campo di destinazione da leggere. Ne discendono due garanzie distinte, che non vanno confuse.

La prima vale per entrambi i KEM e per qualsiasi osservatore:

• I destinatari non possono vedersi tra loro. Ogni slot è una chiave avvolta in modo indipendente. Un destinatario che apre il proprio slot non deduce nulla su nessun altro slot e non può sapere chi altro fosse indicato come destinatario.
• Nessuna chiave pubblica dei destinatari sul wire. Compaiono solo l'incapsulamento per slot (epk o kem_ct) e la chiave avvolta. Un osservatore privo di chiavi candidate non può enumerare i destinatari: apprende soltanto il numero di slot, la famiglia di KEM (enc.kem) e la distinzione tra sigillato e aperto.

La seconda, ovvero l'anonimato del destinatario contro un avversario che possiede già un insieme di chiavi pubbliche candidate e vuole verificare se uno slot è indirizzato a una di esse, è una proprietà più forte e specifica del KEM, e lo standard la rivendica solo per il percorso classico:

• x25519 è riservato sulla chiave (key-private). L'epk per slot è una chiave pubblica effimera fresca, statisticamente indipendente dalla chiave del destinatario. A partire dal solo epk e dal solo wrap, un avversario in possesso delle chiavi non può decidere quale candidato (se mai uno) uno slot prenda di mira, senza la chiave privata corrispondente.
• mlkem768x25519 non la rivendica. L'anonimato del destinatario contro un avversario in possesso delle chiavi è una proprietà a sé, non implicata dalla sicurezza IND-CCA del KEM ibrido, e non è rivendicata per il percorso X-Wing fino a quando non sia giustificata in modo indipendente per X-Wing. Un deployment il cui modello di minaccia richiede l'anonimato del destinatario contro un avversario in possesso delle chiavi NON DEVE affidarsi al percorso ibrido per questa proprietà. Le fughe oneste qui sopra (numero di slot, famiglia di KEM, distinzione tra sigillato e aperto) sono identiche per entrambi i KEM; nulla di più sui destinatari viene esposto su nessuno dei due percorsi.

Vincolo al testo in chiaro

Il digest on-chain si vincola al testo in chiaro, non al testo cifrato. Un destinatario che decifra una PoE sigillata ricalcola l'hash del testo in chiaro e lo confronta con la mappa hashes on-chain. Questo significa che un livello di storage che serve un testo cifrato manomesso viene scoperto dopo la decifratura, indipendentemente dal modello di integrità dell'URI stesso: la rivendicazione sul timestamp è una rivendicazione sul testo in chiaro a cui il mittente si è vincolato, e nulla di ciò che fa il gateway può soddisfarla con byte diversi.

Indipendenza dalla ritrasmissione

Le firme di un record sono fissate nel momento in cui la sua transazione viene inviata. La catena non ha alcuna nozione di un "insieme esteso di firmatari" che si accumula tra più transazioni.

Ritrasmettere un corpo di record identico in una transazione separata con un diverso insieme di sigs crea un record separato e indipendente, con un proprio block time, mai un'estensione dell'originale.

Una parte che voglia avallare un record già pubblicato pubblica un record proprio, che fa riferimento allo stesso contenuto o che punta alla transazione precedente tramite supersedes, firmato con la propria chiave. Non appende un testimone al record di qualcun altro. Di conseguenza, un attaccante che copia i byte di un record firmato in una nuova transazione non diventa co-firmatario dell'originale: produce una rivendicazione successiva e duplicata con le sigs che ha scelto, mentre il block time anteriore dell'originale resta la registrazione canonica dell'esistenza. I verificatori e gli indicizzatori NON DEVONO fondere due transazioni con corpi di record identici in un'unica vista a "firmatari uniti"; farlo falsificherebbe la semantica del block time per ogni record, su cui fanno affidamento i consumatori a valle.

Regole normative per le implementazioni

Le seguenti regole sono normative ai fini della sicurezza per qualsiasi implementazione conforme, a prescindere dal linguaggio o dalla piattaforma. Le parole chiave di RFC 2119 / RFC 8174 sono usate nel senso normativo.

Nessuna crittografia inedita

Label 309 ammette deliberatamente solo primitive ben analizzate, ciascuna nominata nei registri degli algoritmi e implementata da una libreria sottoposta ad audit. Un'implementazione NON DEVE introdurre un cifrario simmetrico, un KDF, un costrutto di firma o una stanza di avvolgimento delle chiavi personalizzati. Il formato wire è una composizione di parti standard, proprio perché la sua sicurezza si riconduca alla sicurezza di quelle parti.

Solo cifratura autenticata

Ogni cifratura simmetrica in Label 309, sia il livello del contenuto sia l'avvolgimento della chiave per ogni slot, è AEAD. Non c'è alcuna modalità di cifrario non autenticata in nessun punto del formato. Un componente di decifratura il cui controllo del tag AEAD fallisce DEVE restituire un errore strutturato con un discriminatore di codice stabile e NON DEVE proseguire restituendo byte non autenticati. I dati autenticati aggiuntivi fanno parte del calcolo del tag, quindi un AAD errato fallisce in modo identico a una chiave errata: non esiste uno stato di successo parziale da sondare.

Confronto a tempo costante dei segreti

Un ciclo di confronto il cui tempo di esecuzione dipende dai byte segreti è un oracolo. Ogni controllo di uguaglianza su un segreto o su un tag MAC/AEAD DEVE avvenire a tempo costante:

• Il MAC dell'insieme di slot e qualsiasi tag HMAC: una fuga temporale byte per byte su un MAC da 32 byte può, in caso di ripetizione da parte dell'attaccante, recuperare il tag.
• La verifica del tag AEAD: la funzione decrypt della libreria sottostante restituisce già un fallimento senza rivelare quale byte non corrispondesse; le implementazioni NON DEVONO reimplementare questo controllo.
• La verifica della firma: usa la funzione verify della libreria, mai un'equazione scritta a mano.

Un semplice == / === su array di byte che toccano una qualsiasi di queste superfici è un difetto. Far passare ogni confronto di questo tipo attraverso un unico helper tipizzato rende la proprietà verificabile in audit.

La disciplina a tempo costante si estende alla forma del ciclo di decifratura per tentativi, non solo ai singoli confronti. Per preservare la proprietà di destinatario nascosto, un verificatore destinatario DEVE elaborare tutti gli slot nel passaggio relativo a una singola chiave privata, ovvero un numero costante di operazioni per slot per ogni chiave, senza alcuna uscita anticipata alla prima corrispondenza, così che un osservatore a livello di rete con accesso ai tempi non possa dedurre quale indice di slot una chiave abbia aperto, né se qualcuna lo abbia fatto. La chiave candidata viene selezionata a tempo costante. La validità della quota X25519 è catturata da un bit indipendente dal segreto, kem_ok = NOT constantTimeEqual(shared, 0^32), calcolato con un confronto a tempo costante anziché con una diramazione anticipata; la KEK è quindi una selezione a tempo costante tra la KEK reale e una KEK fittizia derivata da un segreto condiviso tutto a zero sotto lo stesso salt e info, e kem_ok è incorporato nell'accettazione dello slot (ok = kem_ok AND open_ok AND mac_ok) così che uno slot con ECDH non valido non possa mai essere accettato mentre il ciclo esegue comunque lavoro identico. L'array degli slot viene pubblicato in ordine mescolato con un CSPRNG, perciò la posizione sul wire non veicola già alcun segnale "prima il destinatario principale"; in combinazione con il passaggio a tempo costante, un osservatore apprende soltanto il numero di slot. Un destinatario che detiene più chiavi private (per esempio chiavi archiviate dopo una rotazione d'identità) itera chiave × slot e PUÒ interrompere in anticipo tra una chiave e l'altra, il che fa trapelare soltanto il debole segnale di "quale chiave ha corrisposto", ma DEVE restare a tempo costante sugli slot di ciascuna singola chiave, riderivando la metà del salt della KEK relativa alla chiave per ogni chiave, dato che entrambi i KEM impegnano il salt alla codifica wire canonica di quella chiave (esattamente la chiave pubblica X25519 da 32 byte, oppure esattamente i byte della chiave pubblica X-Wing fissati da 1216 byte, mai una ricodifica non canonica).

Verifica Ed25519 rigorosa

Le firme Label 309 DEVONO essere verificate in modalità rigorosa (canonica). Un verificatore lasco, con cofattore, accetta certe firme malleabili o con chiavi di ordine basso che un verificatore rigoroso rifiuta, il che permetterebbe a due implementazioni conformi di divergere sullo stesso record, infrangendo la proprietà del verdetto unico su cui poggia l'intero standard. Il corpus di conformità multilinguaggio fissa esattamente un vettore di test con chiave di ordine basso proprio per individuare un verificatore scivolato in modalità lasca. Vedi Firme.

Mai registrare materiale segreto

I byte del seed, le chiavi private derivate, le chiavi di cifratura delle chiavi, le chiavi di cifratura del contenuto, il materiale derivato dalla passphrase e il testo in chiaro decifrato NON DEVONO raggiungere i log a nessun livello. L'oscuramento basato sui path nella configurazione di un logger è necessario ma da solo non sufficiente: un valore annidato più in profondità di quanto la glob di oscuramento arrivi a coprire può sfuggire, quindi le implementazioni DEVONO trattare anche ogni valore di tipo byte (Uint8Array, bytes e simili) come opaco e oscurato incondizionatamente, persino per valori pubblici nel protocollo come un nonce. Il segreto meno costoso da proteggere è quello che non entra mai in una riga di log.

Garanzie di costruzione della PoE sigillata

Tre ulteriori proprietà sono specifiche del costrutto di PoE sigillata. Sono normative ai fini della sicurezza per qualsiasi implementazione che produca o apra un record sigillato.

Il MAC dell'insieme di slot è un commitment a ~128 bit

Il MAC dell'insieme di slot è ciò che rende una chiave di contenuto recuperata un commitment all'insieme di slot a cui il destinatario ha corrisposto: un mittente malevolo non può costruire due insiemi di slot distinti che un singolo destinatario accetti entrambi come "propri". La proprietà richiesta è il commitment di chiave ristretto per la chiave di contenuto della busta, nel senso della RFC 9771: la chiave recuperata si lega a un'unica trascrizione di slot, non un AEAD committing completo su input arbitrari. Il destinatario deriva una chiave da uno slot, poi esige che quella stessa chiave riproduca slots_mac sull'hash di trascrizione degli slot prima di trattare lo slot come proprio. Concretamente il commitment poggia sulla resistenza alle collisioni multi-chiave di

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

per CEK e trascrizioni scelte dall'avversario. Poiché l'avversario controlla sia la CEK sia la trascrizione, il limite rilevante è quello della collisione generica (birthday) sull'output HMAC da 256 bit: trovare due coppie (CEK, trascrizione) che producano lo stesso slots_mac è una ricerca da ~128 bit, non al livello di seconda preimmagine da 256 bit. Un margine di collisione generica da 128 bit è il livello di sicurezza su cui questo commitment fa affidamento, ed è adeguato al modello di minaccia.

Comprimere con un pre-hash la trascrizione in un slots_hash da 32 byte prima dell'HMAC non lo indebolisce: una collisione di slots_mac implica o una collisione di slots_hash (una collisione SHA-256) oppure una collisione dell'HMAC con chiave su slots_hash uguali, entrambe al livello di ~128 bit. La resistenza alla manomissione della trascrizione stessa eredita il limite di collisione da 2^128 di SHA-256: qualsiasi modifica a un campo dell'intestazione impegnato o a un byte di slot altera slots_hash, e forgiare uno slots_hash invariato su una trascrizione diversa è esattamente quella ricerca di collisione da ~128 bit. Una conseguenza diretta è che l'avvolgimento per slot non deve essere un AEAD committing: il commitment è fornito da slots_mac, non dall'avvolgimento, perciò un avvolgimento non committing (il ChaCha20-Poly1305 predefinito) è qui sicuro.

La sicurezza dell'avvolgimento a nonce azzerato poggia sull'unicità della chiave per slot

Ogni slot avvolge la chiave di contenuto sotto una chiave di cifratura della chiave per slot con ChaCha20-Poly1305 a un nonce azzerato. Un nonce azzerato è sicuro solo perché la chiave di cifratura della chiave è per slot e usata per esattamente un avvolgimento: ogni slot estrae materiale KEM fresco, perciò la chiave di avvolgimento è unica per slot con probabilità di collisione trascurabile. La condizione di sicurezza è esattamente l'unicità della chiave per slot, e un produttore NON DEVE introdurre nulla che possa ripetere una coppia (chiave, nonce): un fallimento del CSPRNG che ripeta il materiale KEM, un incapsulamento deterministico o in collisione, il riutilizzo di uno slot tra record, la memorizzazione in cache di una chiave derivata per (destinatario, effimera), o la deduplicazione di due occorrenze dello stesso destinatario in un solo slot.

Questo si divide nettamente in una parte verificabile dal verificatore e un obbligo del solo produttore:

• I duplicati all'interno del record sono rifiutati dal verificatore. Un verificatore DEVE esigere che il materiale di incapsulamento sia distinto all'interno di un singolo slots[]: tutti i valori epk distinti sul percorso x25519, tutti i valori kem_ct distinti sul percorso mlkem768x25519. Un duplicato viene rifiutato prima dell'esecuzione di qualsiasi primitiva KEM o AEAD, con il codice tipizzato ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Il corpus di conformità esercita questo caso con un record che porta due slot che condividono un epk (o un kem_ct) ed esige quel rifiuto. Questo rifiuto scatta solo su un epk / kem_ct ripetuto; non vieta di sigillare due volte verso lo stesso destinatario, dato che la duplicazione onesta estrae comunque nuova casualità KEM per slot a ogni comparsa (vedi la regola sulle corrispondenze multiple di slot più sotto).
• Il riutilizzo tra record e tra chiavi è un obbligo del produttore. Nessun verificatore può rilevare che un produttore abbia riutilizzato materiale KEM tra due record o destinatari diversi; ciò sta al di fuori dei byte di un singolo record e resta una responsabilità del produttore. Se una revisione futura permettesse il riutilizzo della chiave, il nonce azzerato dovrebbe essere sostituito con un nonce fresco nella stessa modifica.

Corrispondenze multiple di slot: il riempimento è ammesso, un conflitto di CEK no

Una chiave privata del destinatario PUÒ legittimamente corrispondere a più di uno slot. Sigillare la stessa chiave di contenuto verso lo stesso destinatario in più slot, ciascuno con effimere per slot fresche, è una valida tecnica di riempimento e di privacy: alza il conteggio visibile degli slot senza rivelare che due degli slot condividono un destinatario. È distinta dal rifiuto, all'interno del record, del duplicato di encapsulation sopra: la duplicazione onesta estrae nuova casualità KEM, perciò il suo epk / kem_ct differisce e non fa mai scattare ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Un verificatore DEVE quindi selezionare la chiave di contenuto del primo slot corrispondente e NON DEVE rifiutare solo perché più di uno slot ha corrisposto.

L'unica anomalia che un verificatore DEVE rifiutare è costituita da due slot corrispondenti che recuperano chiavi di contenuto diverse, confrontate a tempo costante. Il ciclo di decifratura per tentativi porta un bit cek_conflict attraverso tutti gli slot e fa emergere l'unico fallimento generico se una qualsiasi corrispondenza successiva recupera una chiave che differisce da quella già selezionata. Questa è difesa in profondità: sotto la proprietà di commitment sopra, una corrispondenza con chiave distinta è già infattibile, essendo esattamente la collisione multi-chiave che quella proprietà esclude, perciò il controllo fallisce in modo chiuso contro un'implementazione difettosa o un futuro indebolimento dell'assunzione. Il negativo con chiave distinta non è costruibile come vettore di byte (costruirne uno sarebbe la collisione del commitment stessa), perciò la proprietà è fissata da test comportamentali a livello di implementazione anziché da una fixture, affiancata da una fixture positiva per la duplicazione legittima del destinatario.

Soglie di risorse del parser prima di qualsiasi primitiva

Un verificatore DEVE limitare l'uso di risorse del parser prima di invocare qualsiasi primitiva KEM o AEAD, così che una busta sovradimensionata non possa imporre lavoro prima di essere rifiutata. Le soglie di riferimento sono MAX_SLOTS = 1024 slot e 65536 byte per la busta enc decodificata, entrambe ben al di sopra del tetto di ~16 KiB dei metadati delle transazioni Cardano che vincola qualsiasi record onesto, perciò un record che superi l'una o l'altra soglia è malformato. Un conteggio eccessivo è rifiutato con ENC_SLOTS_TOO_MANY, una busta sovradimensionata con ENC_ENVELOPE_TOO_LARGE. Queste sono costanti applicate dal verificatore e fissate dal deployment, non campi del wire, e un deployment PUÒ restringerle. La protezione analoga sul percorso passphrase è una lunghezza massima dell'input grezzo della passphrase imposta prima della normalizzazione e di Argon2id (soglia di riferimento 4096 byte UTF-8, MAX_PASSPHRASE_INPUT_BYTES), così che una passphrase patologica non possa provocare un denial-of-service pre-KDF.

La validità della chiave pubblica X-Wing delimita la soglia minima ibrida

Il KEM ibrido mlkem768x25519 non scende mai al di sotto della sicurezza classica di X25519 come soglia minima, ma quella soglia minima è circoscritta alle chiavi del destinatario generate validamente. XWing.Encapsulate DEVE applicare il controllo di validità della chiave pubblica della revisione di X-Wing fissata alla chiave del destinatario e rifiutare di incapsulare verso una chiave che non lo supera, anziché trattare una chiave malformata come se portasse la garanzia classica. Un produttore che salta il controllo rinuncia alla soglia minima per quel destinatario; il controllo è la precondizione sotto cui la soglia minima vale.

Dimensione del payload limitata

Il livello del contenuto è uno STREAM segmentato: il testo in chiaro è suddiviso in chunk da 65536 byte, ciascuno sigillato sotto la chiave del contenuto con un nonce a contatore distinto. Il contatore per chunk a 88 bit ammette 2^88 chunk e ogni chunk resta ampiamente entro il limite a invocazione singola di RFC 8439, perciò — a differenza di un AEAD single-shot sull'intero testo in chiaro — non c'è alcuna collisione di keystream da overflow del contatore da cui difendersi e il formato non impone alcun tetto crittografico al payload. Il massimo che un deployment fa rispettare è quindi una policy contro il denial-of-service, non un limite crittografico: produttori e verificatori DOVREBBERO limitare la dimensione del payload alle proprie risorse e imporla in modo incrementale man mano che lo stream viene scritto o letto, interrompendo prima che un payload sovradimensionato venga bufferizzato. La troncatura viene colta strutturalmente dal flag di fine per ogni chunk — un chunk finale mancante, dati in coda o un chunk non finale troppo corto fanno fallire la decifratura — anziché da un controllo sulla dimensione. Il comportamento è identico sul percorso a slot e sul percorso a passphrase.

L'agilità rispetto agli algoritmi come proprietà di sicurezza

Ogni scelta crittografica in un record Label 309 è nominata da una stringa proveniente da un registro estensibile: l'hash, l'AEAD, il KEM, il KDF, lo schema di firma. Non è una scelta stilistica; è il substrato di migrazione che permette al formato di sopravvivere a qualsiasi singolo algoritmo.

Se una primitiva viene indebolita dalla crittoanalisi:

1. Il registro pertinente acquisisce un identificatore successore. Nulla nel formato esistente cambia: il nuovo nome è additivo.
2. I record esistenti restano validi. Un verificatore continua a riconoscere il vecchio identificatore per i record storici; le loro rivendicazioni sul block time non svaniscono perché esiste un algoritmo più recente. Un'implementazione PUÒ presentare un record che si basa solo su un algoritmo nel frattempo indebolito come a minore affidabilità, ma NON DEVE cancellarlo o rifiutarlo solo su questa base.
3. I nuovi record si pubblicano sotto il successore. Un produttore che voglia una difesa in profondità PUÒ vincolare un hash del contenuto sotto due algoritmi di famiglie di progettazione distinte, così che la compromissione di una singola famiglia non azzeri il valore probatorio del record, anche se i record con un solo algoritmo restano pienamente conformi.

Poiché gli identificatori sono stringhe e i registri sono aperti, migrare verso hash, KEM o firme post-quantistici è una modifica additiva ai registri, mai una revisione del formato che rompe la compatibilità. Il KEM ibrido post-quantistico già presente nel registro è un esempio di questa proprietà in azione, non un caso speciale aggiunto a posteriori.

Limiti noti dello standard

Questi non sono difetti da correggere in una revisione successiva; sono proprietà intrinseche dell'ancorare prove su un registro pubblico permanente e della cifratura a chiave pubblica verso chiavi a lungo termine. Un modello di sicurezza onesto li nomina.

Permanenza on-chain

I metadati Cardano sono permanenti e replicati a livello globale. Un record Label 309 pubblicato non può essere eliminato, oscurato o invalidato: quella durabilità è l'intero senso della Proof of Existence. La conseguenza è una responsabilità al momento della pubblicazione: un hash del contenuto, una firma collegata allo stake o qualsiasi altra cosa vincolata sotto label 309 resta sulla catena per sempre. Label 309 omette deliberatamente dal record i metadati descrittivi in formato libero per mantenere minima l'impronta on-chain, ma un produttore DEVE comprendere, prima di pubblicare, che ciò che pubblica è irrevocabile.

Il numero di destinatari è visibile

Una PoE sigillata non nomina mai i suoi destinatari, ma il numero di slot dei destinatari è la lunghezza dell'array, chiaramente visibile sulla catena, così come lo sono la famiglia di KEM (enc.kem) e la distinzione tra sigillato e aperto. Le chiavi pubbliche dei destinatari sono fuori dal wire e gli slot sono mescolati, ma un riempimento che nasconda il conteggio non fa parte della linea di base. Un mittente per cui il numero di destinatari è di per sé sensibile deve tenere conto di questa fuga di metadati a livello operativo, ad esempio riempiendo l'insieme di slot da sé oppure pubblicando record separati.

Nessuna revoca per singolo destinatario

Non esiste alcuna primitiva on-chain per revocare l'accesso di un singolo destinatario a una PoE sigillata già pubblicata. Una volta che un record è cifrato verso una chiave pubblica e ancorato, quel vincolo è permanente. È una proprietà intrinseca della cifratura a chiave pubblica verso una chiave a lungo termine, non una lacuna del formato. Una chiave che si ritiene compromessa si gestisce d'ora in avanti, indirizzando i nuovi record a una chiave fresca e, facoltativamente, pubblicando un record di sostituzione come segnale di avvertimento, mai tornando indietro ad alterare ciò che è già sulla catena.

Nessuna forward secrecy per il destinatario, per scelta progettuale

Chi detiene la chiave privata di un destinatario può decifrare ogni PoE sigillata mai indirizzata a essa, per sempre. Il testo cifrato off-chain è permanente e non esiste alcuna primitiva di revoca, quindi un record sigillato è privato rispetto al mondo ma non rispetto al suo destinatario. È il comportamento atteso della cifratura verso una chiave pubblica a lungo termine. Un mittente che ha bisogno di limitare la portata futura di un destinatario deve cifrare verso una chiave di destinatario di breve durata anziché verso una chiave d'identità a lungo termine: una scelta lato mittente che il formato consente ma non impone.

I fallimenti della decifratura di prova non rivelano materiale delle chiavi

Un destinatario scopre il proprio slot tramite decifratura di prova. Internamente, e solo per la diagnostica di un chiamante locale fidato, i percorsi di fallimento portano codici tipizzati distinti: "nessuno slot si è aperto con la mia chiave" (WRONG_RECIPIENT_KEY), "uno slot si è aperto ma nessuna chiave candidata ha riprodotto slots_mac" (TAMPERED_HEADER) e "l'AEAD del contenuto è fallito dopo che una chiave è stata recuperata e il MAC verificato" (TAMPERED_CIPHERTEXT). Questi codici non hanno alcun valore di oracolo: un attaccante senza una chiave privata corrispondente non apre alcuno slot, e ogni percorso di errore DEVE escludere dal proprio messaggio e dalla catena delle cause i byte segreti sottostanti (il segreto condiviso, la chiave di cifratura delle chiavi, la chiave di cifratura del contenuto).

Un chiamante esterno non fidato, invece, DEVE ricevere esattamente un'unica forma di fallimento generico a prescindere dal motivo per cui la decifratura è fallita, e la risposta esterna NON DEVE distinguere le tre cause per forma, né rivelare quale slot abbia corrisposto. I codici interni esistono per il debug locale; NON DEVONO trapelare a un osservatore esterno tramite una risposta distinguibile.

Il modello dei tempi è deliberatamente circoscritto. Un verificatore PUÒ ritornare al controllo di mancata corrispondenza, prima della decifratura del contenuto, perciò un non destinatario (nessuno slot aperto) può essere temporizzato a parte da un destinatario il cui slot si è aperto ma il cui testo cifrato di contenuto non si apre. Quella distinzione rivela soltanto destinatario contro non destinatario; non rivela mai quale slot abbia corrisposto, né alcun materiale di chiave. Tempi uniformi tra il caso del non destinatario e il caso del testo cifrato errato non sono richiesti, e un'apertura fittizia del contenuto NON DEVE essere imposta: imporre il costo della decifratura del contenuto a ogni non destinatario non acquisterebbe nulla. La garanzia a tempo costante che vale è l'invariante tra gli slot (vedi Confronto a tempo costante dei segreti): all'interno del passaggio di una singola chiave il ciclo scorre tutti gli slot con confronti a tempo costante, perciò un osservatore non può apprendere quale slot, se mai uno, una data chiave abbia aperto, e oltre alla distinzione destinatario-contro-non, apprende soltanto il numero di slot.

Pagine correlate

• Introduzione: i cinque invarianti, tra cui "indipendente dall'emittente" e "verificabile in autonomia".
• Firme: la verifica Ed25519 rigorosa e il modello di paternità a degrado morbido.
• PoE sigillata: la busta di cifratura e le proprietà di riservatezza qui riassunte.
• Registri degli algoritmi: gli identificatori nominati che rendono possibile l'agilità rispetto agli algoritmi.
• Verifica: la pipeline, la politica di profondità delle conferme e il catalogo degli errori.