CESS — Kryptologisch verzaubertes Shamir-Geheimnis

Ist das KI-Unsinn oder Schrott?

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).

Warum CESS existiert

Bestehende Ökosysteme adressieren Teile dieses Problems, lassen aber Lücken:

• GnuPG bietet starke Verschlüsselung und Signierung, aber kein normatives, interoperables Profil für Shamir-Shares plus moderne AEAD und standortübergreifende Treuhand-Workflows.
• Autocrypt konzentriert sich auf opportunistische E-Mail-Verschlüsselung, nicht auf Threshold-Splitting von langfristigen Geheimnissen mit PIN-geschützten Shares.
• SLIP-0039 standardisiert mnemonische Kodierung von Shamir-Shares für Seeds; CESS ergänzt diesen Bereich mit einem binären Share-Envelope, expliziter Cipher-Aushandlung, Brainpool-ECDH-Profilen, Argon2id-basierter PIN-Handhabung und CESS-PQ-Hybrid-Kombinatoren.

CESS definiert den Standard; SplitDisk (und ähnliche Produkte) sind Referenzszenarien und Beispielbereitstellungen, nicht der Standard selbst.

Cipher-agnostisches Design

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).

Prüfauflage und Ausschlüsse (Zusammenfassung)

• Jedes Primitiv in der cipher-agnostischen Schicht MUSS zwei oder mehr unabhängige Bewertungen aus der qualifizierten Prüferliste haben (NESSIE, CRYPTREC, ECRYPT/eSTREAM, IACR-Peer-Review, BSI, NCC Group, Cure53, Kudelski Security, JP Aumasson, PHC-Komitee).
• NSA-Entwurfseinfluss, NIST/FIPS-Only-Prüfung und mehrere Algorithmen (AES, SHA-2, SHA-3, NIST-Kurven, ML-Kyber, Dual_EC_DRBG, RC4, DES, 3DES, HMAC-SHA-*) sind mit expliziter Begründung in der Spezifikation ausgeschlossen.
• X25519 / Ed25519 sind optional mit dokumentierter Begründung zulässig (Bernstein-Entwürfe; umfangreiche unabhängige Prüfungen).

Warum NIST-Primkurven (P-256, P-384, P-521) weggelassen werden

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).

Klassisches ECDH in CESS verwendet Brainpool-Kurven (RFC 5639) stattdessen. Ihre Parameter werden durch veröffentlichte Generierungsregeln erzeugt und sie sind eine natürliche Wahl für BSI-orientierte und EU-zentrierte Diskussionen, während sie vergleichbare Sicherheitsziele abdecken (z.B. BrainpoolP384r1 vs. P-384-Klassensicherheit) ohne die ausgeschlossene NIST-Kurvenfamilie zu übernehmen.

Details: spec/CESS-v0.2.md Abschnitt 3, spec/CRYPTO.md und ALGORITHM-REGISTRY.md.

Repository-Layout

Lizenzierung

Patente und OIN

Beitragende stimmen der Patent-Nichtangriffsklausel in PATENTS.md zu. Das Projekt ist beim Open Invention Network (OIN) registriert, einem defensiven Patentpool für Linux-bezogene Open-Source-Software. Die Kreuzlizenzierung über OIN deckt nicht von sich aus Parteien außerhalb dieses Ökosystems ab; die Klausel soll diese Lücke für konforme Implementierungen schließen.

Zielgruppen

• Kryptografen und Protokollingenieure
• Regierungsbehörden und Verteidigungsauftragnehmer (insbesondere EU-zentrierte Beschaffung)
• Anbieter von Hardware-Sicherheitstoken und Smartcards (CCID-Profil)
• Open-Source-Entwickler, die Threshold-Verwahrungs- und Disaster-Recovery-Tools entwickeln

Beitragen

Siehe CONTRIBUTING.md. Pull Requests gelten als Zustimmung zu PATENTS.md. Spezifikationsänderungen erfordern zwei Prüfer in verschiedenen Ländern. Neue Algorithmen verwenden ALGORITHM-REGISTRY.md (öffnen Sie einen PR gegen das Register, dann ggf. gegen Querverweise in spec/CESS-v0.2.md).

Hinzufügen einer Chiffre zum Register

1. Bestätigen Sie zwei qualifizierte Prüfungen und das Fehlen von harten Ausschlüssen.
2. Öffnen Sie einen PR, der ALGORITHM-REGISTRY.md bearbeitet (Nachweistabelle, Kennungszuweisung).
3. Fügen Sie Testvektoren unter vectors/ hinzu oder erweitern Sie sie, die die neue Suite abdecken.
4. Holen Sie zwei Maintainer-Reviews gemäß CONTRIBUTING.md ein.

Dokumentenverzeichnis

• Glossar (nicht-technisch A–Z)
• Hauptstandard
• CRYPTO (Begründung)
• GOVERNMENT (Bereitstellung)
• Algorithmenregister
• Konformität
• Konformitäts-Runner / innere Kaskaden-KATs
• Vektoren-Leitfaden
• Test-Runner
• Patente

Beziehung zu SplitDisk

CESS ist der Standard. SplitDisk ist ein beispielhaftes Implementierungsszenario (z.B. Festplattenverschlüsselung plus Share-Verteilung); die Werkzeugspezifikation lebt in diesem Repository. Produkte können CESS-CORE, CESS-FULL oder CESS-PQ-Konformität gemäß CONFORMANCE.md beanspruchen, ohne den Namen SplitDisk zu verwenden.