Divulgazione riservata senza pubblicare il file

Puoi dimostrare che un file esisteva in un dato momento senza renderlo pubblico.

È esattamente quello che fa un record Label 309 sigillato. Il mittente calcola l'hash del testo in chiaro, cifra il file e pubblica un record di prova su Cardano. Il testo cifrato è conservato in una posizione indirizzata per contenuto e reso disponibile solo ai detentori della chiave che possono decifrarlo. La blockchain pubblica dimostra che un determinato impegno esisteva entro un orario di blocco pubblico; il testo in chiaro resta leggibile solo dal pubblico scelto.

Tutto questo si adatta al lavoro legale, di compliance, di sicurezza, giornalistico, con i partner e alle indagini interne — ovunque la cronologia conti ma il documento non debba finire pubblicato in rete, alla portata di tutti.

Cosa significa qui divulgazione riservata?

Significa condividere prove con un pubblico specifico anziché con il mondo intero.

Quel pubblico può essere un avvocato, un revisore, un'autorità di regolamentazione, un giornalista, un team di indagine interna, il referente di sicurezza di un cliente, un comitato del consiglio, un partner — oppure una versione futura di te stesso.

L'obiettivo è dimostrare che le prove esistevano in un dato momento senza mettere il testo in chiaro su una blockchain pubblica o su un sito web pubblico. La Proof of Existence sigillata è costruita esattamente per questa forma: una rivendicazione pubblica del tempo su un file privato.

Cosa finisce davvero sulla catena pubblica?

Il record di prova diventa pubblico. Il testo in chiaro no.

Il record on-chain può contenere:

l'hash del testo in chiaro — è questa la prova del timing;
l'orario di blocco della transazione Cardano;
una busta di cifratura che racchiude il materiale di chiave incapsulato;
uno o più URI di testo cifrato indirizzati per contenuto (ar:// o ipfs://);
una firma opzionale, se il mittente decide di firmare;
una Merkle root, se la divulgazione copre molti file contemporaneamente.

Il record deliberatamente non contiene:

il file in chiaro;
una lista leggibile dei destinatari;
la chiave privata di alcun destinatario;
il tuo Identity Seed;
le prove decifrate.

Una sfumatura che vale la pena dire chiaramente: nemmeno le chiavi pubbliche dei destinatari compaiono sulla catena. Un destinatario non è nominato nel record — scopre che un record è suo solo riuscendo a decifrarlo a tentativi. Un osservatore capisce che un record è sigillato, ne vede l'hash del testo in chiaro e l'orario di blocco, e può contare gli slot di chiave incapsulati, ma gli slot vengono mescolati in un ordine casuale e sicuro prima della pubblicazione: così persino «prima il destinatario principale» non rivela nulla. Il conteggio ti dice quanti, mai chi.

Il testo cifrato in sé può essere scaricato da chiunque abbia l'URI. Senza una chiave corrispondente, resta illeggibile.

Come fa un destinatario ad aprire un record sigillato?

Il destinatario condivide un indirizzo di ricezione con il mittente, e il mittente sigilla il record verso di esso.

Un indirizzo di ricezione non è altro che una chiave pubblica. Il mittente incapsula la chiave di cifratura del file verso quell'indirizzo. In seguito, il client del destinatario scansiona i record Label 309 pubblici e prova ad aprire gli slot di chiave cifrati di ciascun record con le proprie chiavi di ricezione private — tutto in locale, sul dispositivo del destinatario. L'informazione su quali record gli appartengano non lascia mai la macchina.

Quando uno slot si apre, il client recupera il testo cifrato, lo decifra, ricalcola l'hash del testo in chiaro e lo confronta con l'impegno on-chain. Una corrispondenza conferma due cose in una sola volta: il destinatario ha il file vero, e quel file esatto è quello impegnato all'orario di blocco registrato.

Poiché il destinatario detiene una chiave privata, è qui che la verifica passa da «un impegno esisteva» a «questo contenuto specifico esisteva». Per i meccanismi lato mittente — condividere un indirizzo di ricezione e ricevere record sigillati — vedi come ricevere record sigillati.

Perché non inviare semplicemente il file cifrato via email?

L'email può spostare i file, ma non è un timestamp durevole e verificabile in modo indipendente.

Un messaggio può essere cancellato, alterato o perso. Gli allegati vengono rimossi. I server di posta vengono dismessi. I formati di export sono disordinati e difficili da autenticare a distanza di anni. Niente di tutto questo offre a un verificatore un modo per dimostrare quando il file esisteva.

Un record Label 309 sigillato dà al file un'àncora di prova pubblica che non dipende dalla tua casella di posta né dal server di qualcuno. Il payload cifrato può essere conservato a parte, e il destinatario può in seguito dimostrare che il contenuto decifrato corrisponde a un hash impegnato su una catena pubblica. Puoi comunque avvisare il destinatario via email — solo, non far dipendere la prova da essa.

Perché non caricare semplicemente il file cifrato su uno storage privato?

Puoi farlo, e spesso dovresti. Ma lo storage privato da solo non ti dà alcuna àncora di tempo pubblica.

Un bucket di storage aziendale, uno strumento di gestione dei casi o un portale sicuro possono benissimo custodire file cifrati. Ciò a cui nessuno di essi risponde da solo è: può un verificatore successivo dimostrare quando quel pacchetto cifrato esisteva, e che il testo in chiaro decifrato corrisponde a un impegno pubblico? Senza questo, «avevamo questo file a marzo» è un'affermazione, non una prova.

Label 309 aggiunge l'impegno con timestamp. Non sostituisce il tuo storage sicuro — vi aggiunge sopra uno strato di prova verificabile.

Quando andrebbe firmato il record di divulgazione?

Firmalo quando la responsabilità conta più dell'anonimato.

Firmare un record è opzionale. Una firma permette a una specifica chiave di identità di garantire per la divulgazione — utile quando un'azienda invia un pacchetto di prove formale a un revisore, o quando un team legale ha bisogno di un record responsabile e attribuibile. La firma è una rivendicazione di paternità basata su chiave pubblica, e un verificatore può controllarla senza fidarsi di alcun server.

Lascia il record non firmato quando conta di più l'anonimato del mittente. Un record sigillato non firmato non vincola alcuna identità del mittente sulla catena, ed è esattamente ciò di cui hanno bisogno le segnalazioni di whistleblower e gli scenari a busta chiusa. Il compromesso dovrebbe essere una scelta deliberata: una firma può stabilire chi ha avallato la divulgazione, e in contesti delicati quella stessa attribuzione può rivelare più di quanto il mittente desideri.

Un solo record può raggiungere più destinatari?

Sì. Un singolo record sigillato può incapsulare la chiave di cifratura del file in slot separati per più destinatari.

Ogni destinatario apre il record con la propria chiave, e un destinatario non può usare il proprio slot per ricavare la chiave di un altro destinatario. Questo copre uno studio legale e il suo cliente, un team di indagine interna, un revisore e un referente aziendale, più autorità di regolamentazione in una volta sola, un comitato del consiglio — oppure un mittente che conserva una copia recuperabile per sé mentre la condivide con altri.

Il record pubblico può rivelare il numero di slot, ma mai una lista leggibile di a chi appartengono.

E un grande pacchetto di prove con molti file?

Usa un manifesto e il Merkle batching invece di una transazione per file.

Calcola l'hash di ogni file in una foglia, riduci le foglie a un'unica Merkle root e pubblica solo quella root nel record Label 309. Sigilla il manifesto e i file di supporto secondo necessità. In seguito, un destinatario o un revisore può verificare qualsiasi singolo file con una breve inclusion proof — interamente offline — invece di trattare l'intero pacchetto come un archivio opaco. Le inclusion proof crescono solo con il logaritmo della dimensione del batch, quindi una divulgazione da mille file si verifica comunque elemento per elemento.

È lo stesso schema una-root-per-molti-file descritto in un solo record per migliaia di file; qui rende le grandi divulgazioni ispezionabili anziché tutto-o-niente.

Cosa dimostra davvero un record sigillato?

Le rivendicazioni sono solide, ma sono specifiche. Un record Label 309 sigillato può mostrare:

che quei dati esatti esistevano entro un orario di blocco pubblico;
che il testo cifrato decifrato corrisponde all'hash del testo in chiaro impegnato;
che una chiave specifica ha firmato il record, se il record è firmato;
che un file specifico era incluso in un insieme di prove raggruppato alla Merkle;
che un destinatario che detiene la chiave e il testo cifrato aveva accesso a prove decifrabili.

Ciascuna di queste è un'affermazione precisa e verificabile in modo indipendente su timing e integrità.

Cosa non dimostra?

Altrettanto importante, ecco cosa non stabilisce:

Non dimostra che le prove siano vere. Una prova certifica byte e timing, non fatti.
Non dimostra che il mittente avesse il diritto legale di divulgare il file.
Non dimostra l'identità reale del destinatario, a meno che l'indirizzo di ricezione non sia stato verificato tramite un processo fidato. Confermare chi possiede davvero un indirizzo è un passaggio a parte — vedi verifica un destinatario prima di sigillare un file.
Non garantisce l'anonimato. Schemi temporali, metadati di rete, tracce del gateway e dei pagamenti, impronte del dispositivo ed errori operativi possono tutti rivelare informazioni che vivono al di fuori del record. Un destinatario può anche far trapelare il testo in chiaro una volta che l'ha decifrato.
Non sostituisce la consulenza legale né le procedure di divulgazione sicura, e se una determinata prova aiuti in una controversia dipende dalla giurisdizione.

Per la versione generale di questo confine, vedi cosa una prova non dimostra.

Come dovrebbe prepararsi un team prima di averne bisogno?

Definisci il flusso di divulgazione prima della crisi, non durante. Decidi in anticipo:

chi può creare divulgazioni sigillate;
quale identità, se ce n'è una, firma i record formali;
quali indirizzi di ricezione sono fidati, e come sono stati verificati;
dove è conservato il testo cifrato;
chi è autorizzato a decifrare;
come sono strutturati i manifesti per i pacchetti multi-file;
come vengono registrati e consegnati i riferimenti delle transazioni;
come vengono esportate le prove per la revisione legale.

La crittografia è solo uno strato. È il processo che le ruota attorno a determinare se la prova sarà davvero utile quando arriva la pressione. Per una prospettiva sulla gestione delle prove, vedi prove legali ed e-discovery e, per le fonti a maggior rischio, prove dei whistleblower.

In breve

La divulgazione riservata ha bisogno di due cose insieme: privacy e prova.

I record Label 309 sigillati mantengono il file cifrato per i detentori di chiave scelti, mentre pubblicano un impegno pubblico, con timestamp, sul suo hash. I destinatari decifrano in locale e confermano che il testo in chiaro corrisponde all'hash on-chain. Firme, Merkle root e slot multi-destinatario aggiungono opzioni di workflow più solide quando ti servono.

Usalo per dimostrare la cronologia senza mai pubblicare il file.

Letture di approfondimento

Label 309 — lo standard di Proof of Existence aperto e neutrale rispetto al fornitore alla base dei record sigillati. Label 309 è la label dei metadati on-chain; la proposta è in fase di revisione nel processo CIP di Cardano come CIP di categoria Metadata (PR aperta).
CardanoWall open source — il corpus dello standard, gli SDK e lo strumento da riga di comando cardanowall, capace di costruire, sigillare e verificare i record.
Cosa una prova non dimostra — i limiti di qualunque Proof of Existence.
Verifica un destinatario prima di sigillare un file — l'errore umano più comune nei flussi di lavoro cifrati.