CESS — Segreto di Shamir Crittologicamente Incantato

Questa è fuffa AI o robaccia?

Un crittografo o un implementatore serio che esamina CESS aprirà di solito vectors/ e testdata/ prima di leggere la prosa. La suite di test è la prova del lavoro: codifica una conoscenza del dominio che non può essere sostituita con la sola narrazione.

Questo non è un motivo per nascondere il punto a tutti gli altri. Le persone che valutano il progetto per l'approvvigionamento, che decidono se contribuire, che scrivono policy o che distribuiscono codice senza una formazione approfondita nella metodologia di test crittografico meritano comunque un puntatore alle prove concrete. Il repository già afferma le regole di audit e le esclusioni di algoritmi; collegare quella storia a vettori di test pubblicati colma il divario tra "affermazioni sulla pagina" e "manufatti che puoi eseguire".

Cosa guardare: Il materiale di conformità include esempi elaborati RFC 8439 per ChaCha20-Poly1305 (l'AEAD IETF che questo progetto riferisce normativamente) e JSON Wycheproof fornito per i casi limite ChaCha20-Poly1305 sotto testdata/wycheproof/. Insieme ai vettori TOML del progetto in vectors/, sono la verità di base che il runner e i revisori possono verificare.

RFC 8439 è pubblicata dall'Internet Engineering Task Force (IETF), l'organizzazione che standardizza gran parte di come Internet interoperi. RFC (Request for Comments) sono la forma usuale per i protocolli e molte specifiche crittografiche. RFC 8439 definisce la crittografia autenticata ChaCha20-Poly1305 (basandosi sui progetti di Daniel Bernstein) e include esempi concreti con input specifici e output attesi in modo che le implementazioni indipendenti possano verificare di corrispondere allo standard byte per byte. Il testo semplice ampiamente riprodotto che inizia con Ladies and Gentlemen of the class of '99: wear sunscreen appare negli esempi dell'appendice della RFC: se il tuo codice riproduce esattamente l'output AEAD, hai una forte verifica di aver implementato correttamente la costruzione. È l'analogo crittografico di un foglio di risposte ufficiale. (La RFC 7539 precedente documentava ChaCha20 e Poly1305 per altri contesti IETF; RFC 8439 è il riferimento usuale per questo AEAD come usato qui e in spec/CESS-v0.2.md.)

Wycheproof è un corpus di test rilasciato dal team di sicurezza di Google (2017). Il nome si riferisce al Monte Wycheproof in Australia — spesso citato come la montagna più piccola del mondo — perché il progetto si concentra sul superare ostacoli piccoli ma fatale: overflow di interi, casi limite, input malformati e tag di autenticazione manomessi; fallimenti che si presentano ripetutamente nella crittografia reale distribuita. Completa i vettori in stile RFC: gli esempi RFC 8439 dimostrano la correttezza rispetto all'AEAD pubblicato; Wycheproof sollecita la robustezza dove le implementazioni storicamente si rompono.

Cosa questo dice su questo standard è una decisione del lettore ben informato.

Si può anche verificare l'integrità delle crate con questo quando la PR sarà chiusa: https://github.com/rust-lang/cargo/issues/16850

Versione: 0.2
Stato: Solo specifica (testo normativo e vettori di test)

Questo progetto è registrato con l'Open Invention Network (OIN), un pool di brevetti difensivo che protegge il software open source relativo a Linux. La combinazione di pubblicazione aperta in preprint (che stabilisce prior art), appartenenza OIN e licenza GPL-3.0 è intesa a garantire che questa tecnologia rimanga liberamente disponibile e non possa essere proprietarizzata o limitata da alcun stato o attore commerciale.

CESS è uno standard crittografico aperto per condivisione di segreti a soglia combinata con crittografia autenticata agnostica rispetto al cifrario, incapsulamento delle condivisioni basato su password e scambio di chiavi ibrido post-quantistico opzionale. È progettato per distribuzioni che richiedono riservatezza a lungo termine, enrollment air-gapped, binding a token hardware e percorsi di approvvigionamento indipendenti da linee di base algoritmiche solo NSA/NIST.

I lettori non tecnici possono iniziare con il glossario (termini in linguaggio semplice A–Z).

Perché CESS esiste

Gli ecosistemi esistenti affrontano parti di questo problema ma lasciano lacune:

• GnuPG fornisce crittografia e firma forti, ma non un profilo normativo e interoperabile per condivisioni Shamir più AEAD moderno e workflow di escrow cross-giurisdizionali.
• Autocrypt si concentra sulla crittografia opportunistica delle email, non sulla suddivisione a soglia di segreti a lungo termine con condivisioni protette da PIN.
• SLIP-0039 standardizza la codifica mnemonica delle condivisioni Shamir per seed; CESS completa questo spazio con un involucro di condivisione binario, una negoziazione esplicita del cifrario, profili ECDH Brainpool, gestione PIN basata su Argon2id e combinatori ibridi CESS-PQ.

CESS definisce lo standard; SplitDisk (e prodotti simili) sono scenari di riferimento e distribuzioni di esempio, non lo standard stesso.

Design agnostico rispetto al cifrario

CESS fissa la condivisione segreta di Shamir su GF(2^8) e diverse primitive di integrità e password non opzionali sottoposte ad audit. Tutti i livelli di crittografia bulk, KEM, KDF e MAC sono selezionabili da un registro sottoposto ad audit, soggetto alla regola dei due auditor indipendenti e alla lista di esclusione dura (vedi spec/CESS-v0.2.md e ALGORITHM-REGISTRY.md).

Requisito di audit ed esclusioni (riepilogo)

• Ogni primitiva nel livello agnostico rispetto al cifrario DEVE avere due o più valutazioni indipendenti dalla lista di auditor qualificanti (NESSIE, CRYPTREC, ECRYPT/eSTREAM, revisione paritaria IACR, BSI, NCC Group, Cure53, Kudelski Security, JP Aumasson, comitato PHC).
• Input di progettazione NSA, revisione solo NIST/FIPS e diversi algoritmi (AES, SHA-2, SHA-3, curve NIST, ML-Kyber, Dual_EC_DRBG, RC4, DES, 3DES, HMAC-SHA-*) sono esclusi con motivazione esplicita nella specifica.
• X25519 / Ed25519 sono opzionalmente consentiti con motivazione documentata (progetti di Bernstein; ampi audit indipendenti).

Perché le curve prime NIST (P-256, P-384, P-521) sono omesse

Le curve prime NIST ampiamente utilizzate nel governo e nell'industria statunitensi (P-256, P-384, P-521) sono state scelte attraverso un processo in cui la NSA ha avuto un ruolo documentato. CESS non si basa su una singola prova matematica che quelle curve siano deboli; applica un'esclusione di policy affinché lo standard possa servire percorsi di approvvigionamento, collegamento e ingegneria che richiedono crittografia giustificata al di fuori di una linea di base solo NSA/NIST e che favoriscono primitive sottoposte a revisione indipendente (vedere sezione 3 di spec/CESS-v0.2.md e ALGORITHM-REGISTRY.md).

ECDH classico in CESS utilizza curve Brainpool (RFC 5639) al suo posto. I loro parametri sono prodotti da regole di generazione pubblicate e sono una scelta naturale per discussioni allineate al BSI e centrate sull'UE, coprendo obiettivi di forza comparabili (ad esempio BrainpoolP384r1 vs sicurezza di classe P-384) senza adottare la famiglia esclusa di curve NIST.

Dettagli: sezione 3 di spec/CESS-v0.2.md, spec/CRYPTO.md e ALGORITHM-REGISTRY.md.

Layout del repository

Licenze

Brevetti e OIN

I contributori accettano il covenant di non-assertione dei brevetti in PATENTS.md. Il progetto è registrato con l'Open Invention Network (OIN), un pool di brevetti difensivo per software open source relativo a Linux. La licenza incrociata tramite OIN non copre di per sé le parti al di fuori di tale ecosistema; il covenant è inteso a colmare tale divario per le implementazioni conformi.

Pubblico

• Crittografi e ingegneri di protocollo
• Agenzie governative e appaltatori della difesa (soprattutto approvvigionamento centrato sull'UE)
• Fornitori di token di sicurezza hardware e smartcard (profilo CCID)
• Sviluppatori open source che costruiscono strumenti di custodia a soglia e disaster recovery

Come contribuire

Vedi CONTRIBUTING.md. Le pull request sono considerate come accordo con PATENTS.md. Le modifiche alla specifica richiedono due revisori in paesi diversi. I nuovi algoritmi utilizzano ALGORITHM-REGISTRY.md (apri una PR sul registro, poi su spec/CESS-v0.2.md riferimenti incrociati se necessario).

Aggiungere un cifrario al registro

1. Conferma due audit qualificanti e assenza di esclusioni dure.
2. Apri una PR modificando ALGORITHM-REGISTRY.md (tabella delle evidenze, allocazione dell'identificatore).
3. Aggiungi o estendi i vettori di test sotto vectors/ coprendo la nuova suite.
4. Ottieni due revisioni dei manutentori secondo CONTRIBUTING.md.

Indice dei documenti

• Glossario (non tecnico A–Z)
• Standard principale
• CRYPTO (motivazione)
• GOVERNMENT (distribuzione)
• Registro algoritmi
• Conformità
• Esecutore di conformità / KAT a cascata interna
• Guida ai vettori
• Esecutore di test
• Brevetti

Relazione con SplitDisk

CESS è lo standard. SplitDisk è uno scenario di implementazione di esempio (ad esempio crittografia del disco più distribuzione delle condivisioni); la specifica dello strumento risiede in quel repository. I prodotti possono dichiarare conformità CESS-CORE, CESS-FULL o CESS-PQ secondo CONFORMANCE.md senza utilizzare il nome SplitDisk.