supermagnum/cessKryptologisch verzaubertes Shamir's Secret
Ein Kryptograf oder ein ernsthafter Implementierer, der CESS prüft, öffnet in der Regel zuerst vectors/ und testdata/, bevor er den Prosa-Teil liest. Die Testsuite ist der Beweis der Arbeit: Sie kodiert Domänenwissen, das sich nicht allein durch Erzählungen ersetzen lässt.
Das ist kein Grund, den Punkt vor allen anderen zu verbergen. Personen, die das Projekt für die Beschaffung bewerten, entscheiden, ob sie einen Beitrag leisten, Richtlinien schreiben oder Code ausliefern, ohne eine tiefgehende Ausbildung in kryptografischen Testmethoden zu haben, verdienen dennoch einen Hinweis auf die konkreten Beweise. Das Repository gibt bereits Prüfregeln und Algorithmenausschlüsse an; die Verknüpfung dieser Geschichte mit veröffentlichten Testvektoren schließt die Lücke zwischen „Behauptungen auf der Seite“ und „Artefakten, die man ausführen kann“.
Was man sich ansehen sollte: Das Konformitätsmaterial enthält RFC 8439-Arbeitsbeispiele für ChaCha20-Poly1305 (die IETF-AEAD, auf die dieses Projekt normativ verweist) und eingebettetes Wycheproof-JSON für ChaCha20-Poly1305-Randfälle unter testdata/wycheproof/. Zusammen mit den projekteigenen TOML-Vektoren in vectors/ bilden sie die Grundwahrheit, die der Runner und die Prüfer ausführen können.
RFC 8439 wird von der Internet Engineering Task Force (IETF) veröffentlicht, der Organisation, die einen Großteil der Interoperabilität des Internets standardisiert. RFCs (Request for Comments) sind die übliche Form für viele Protokoll- und kryptografische Spezifikationen. RFC 8439 definiert die authentifizierte Verschlüsselung mit ChaCha20-Poly1305 (aufbauend auf Daniel Bernsteins Entwürfen) und enthält konkrete Arbeitsbeispiele mit bestimmten Eingaben und erwarteten Ausgaben, damit unabhängige Implementierungen überprüfen können, ob sie dem Standard bytegenau entsprechen. Der viel zitierte Klartext, der mit Ladies and Gentlemen of the class of '99: wear sunscreen beginnt, erscheint in den Anhangsbeispielen der RFC: Wenn Ihr Code die AEAD-Ausgabe exakt reproduziert, haben Sie eine starke Überprüfung, dass Sie die Konstruktion korrekt implementiert haben. Es ist das kryptografische Äquivalent eines offiziellen Lösungsschlüssels. (Die frühere RFC 7539 dokumentierte ChaCha20 und Poly1305 für andere IETF-Kontexte; RFC 8439 ist die übliche Referenz für diese AEAD, so wie sie hier und in spec/CESS-v0.2.md verwendet wird.)
Wycheproof ist ein Testkorpus, der vom Google-Sicherheitsteam (2017) veröffentlicht wurde. Der Name bezieht sich auf den Mount Wycheproof in Australien – oft als kleinster Berg der Welt bezeichnet –, weil sich das Projekt auf die Beseitigung kleiner, aber tödlicher Hürden konzentriert: Ganzzahlüberläufe, Grenzfälle, fehlerhafte Eingaben und manipulierte Authentifizierungstags; Fehler, die in der Praxis immer wieder in eingesetzter Kryptographie auftreten. Es ergänzt RFC-artige Vektoren: RFC 8439-artige Beispiele demonstrieren Korrektheit gegenüber der veröffentlichten AEAD; Wycheproof testet die Robustheit an Stellen, an denen Implementierungen in der Vergangenheit brachen.
Was das über diesen Standard aussagt, bleibt dem gut informierten Leser überlassen.
Man kann auch die Integrität von Crates mit diesem Tool überprüfen, wenn der PR geschlossen ist: https://github.com/rust-lang/cargo/issues/16850
Version: 0.2
Status: Nur Spezifikation (normativer Text und Testvektoren)
Dieses Projekt ist beim Open Invention Network (OIN) registriert, einem defensiven Patentpool zum Schutz von Linux-bezogener Open-Source-Software. Die Kombination aus offener Vorabdruckveröffentlichung (Begründung des Standes der Technik), OIN-Mitgliedschaft und GPL-3.0-Lizenzierung soll sicherstellen, dass diese Technologie frei verfügbar bleibt und von keinem staatlichen oder kommerziellen Akteur proprietär gemacht oder eingeschränkt werden kann.
CESS ist ein offener kryptografischer Standard für Threshold Secret Sharing kombiniert mit cipher-agnostischer authentifizierter Verschlüsselung, passwortbasierter Share-Umschließung und optionalem Post-Quantum-Hybrid-Schlüsselaustausch. Es ist für Einsätze konzipiert, die langfristige Vertraulichkeit, abgeschottete Registrierung, Hardware-Token-Bindung und Beschaffungswege erfordern, die unabhängig von NSA/NIST-Only-Algorithmusbaselines sind.
Nicht-technische Leser können mit dem Glossar beginnen (allgemeinverständliche Begriffe A–Z).
Bestehende Ökosysteme adressieren Teile dieses Problems, lassen aber Lücken:
CESS definiert den Standard; SplitDisk (und ähnliche Produkte) sind Referenzszenarien und Beispielbereitstellungen, nicht der Standard selbst.
CESS legt Shamir's Secret Sharing über GF(2^8) und mehrere geprüfte nicht-optionale Integritäts- und Passwort-Primitive fest. Alle Bulk-Verschlüsselungs-, KEM-, KDF- und MAC-Schichten sind auswählbar aus einem geprüften Register, unterliegen der Zwei-unabhängige-Prüfer-Regel und der harten Ausschlussliste (siehe spec/CESS-v0.2.md und ALGORITHM-REGISTRY.md).
Die NIST-Primkörper-Kurven, die in der US-Regierung und -Industrie weit verbreitet sind (P-256, P-384, P-521), wurden durch einen Prozess ausgewählt, bei dem die NSA eine dokumentierte Rolle spielte. CESS stützt sich nicht auf einen einzigen mathematischen Beweis, dass diese Kurven schwach sind; es wendet einen Policy-Ausschluss an, damit der Standard Beschaffungs-, Verbindungs- und Engineering-Wege bedienen kann, die Kryptographie erfordern, die außerhalb einer NSA/NIST-Only-Baseline gerechtfertigt ist, und die unabhängig geprüfte Primitive bevorzugen (siehe spec/CESS-v0.2.md Abschnitt 3 und ALGORITHM-REGISTRY.md).
