Grundlagenleitfaden
Blockchains mit Unterstützung für Kyber und Dilithium
Kyber und Dilithium sind heute NIST-Standards mit den Namen ML-KEM und ML-DSA. Die schwierigere Frage lautet, welche Blockchain-Projekte sie tatsächlich integriert haben, für welche Funktion und mit welchem Reifegrad. Dieser Leitfaden bietet einen strengen Evidenzrahmen.
Suchergebnisse zu „Blockchains mit Unterstützung für Kyber/Dilithium“ vermischen oft vier sehr unterschiedliche Dinge: eine Kryptografiebibliothek, einen akademischen Prototyp, eine angekündigte Roadmap und eine produktive Konsens- oder Wallet-Implementierung. Sie sind nicht austauschbar. Das ist wichtig, weil Blockchains Kryptografie an vielen Stellen einsetzen und eine teilweise Migration zugleich wertvoll und unvollständig sein kann.
Die kurze Antwort ist vorsichtig: Öffentlich zugängliche, unabhängig überprüfbare Nachweise für eine protokollweite Mainnet-Einführung sowohl von ML-KEM als auch ML-DSA bleiben begrenzt. Das ist keine Kritik an einem Projekt. Die Post-Quanten-Migration verändert Transaktionsformate, Schlüsselverwahrung, Validierungskosten, Bridges, Client-Software und Betrieb. Ein hilfreicher Leitfaden sollte präzise Nachweise statt weit gefasster Behauptungen belohnen.
Zuerst die aktuellen Namen richtig verwenden
Die früheren Namen sind weiterhin verbreitet, doch die Sprache der Standards hilft Teams, Kompatibilität und Implementierungsumfang zu beurteilen.
FIPS 203
ML-KEM, früher Kyber
ML-KEM ist ein auf Modulgittern basierender Mechanismus zur Schlüsselverkapselung. Er ermöglicht zwei Parteien, über einen öffentlichen Kanal ein gemeinsames Geheimnis zu vereinbaren und dieses dann mit symmetrischer Kryptografie für Aufgaben wie Verschlüsselung und Authentifizierung zu nutzen. NIST hat FIPS 203 am 13. August 2024 mit drei Parametersätzen finalisiert: ML-KEM-512, ML-KEM-768 und ML-KEM-1024.
FIPS 203 lesenFIPS 204
ML-DSA, früher Dilithium
ML-DSA ist ein auf Modulgittern basierender Standard für digitale Signaturen, abgeleitet von CRYSTALS-Dilithium. Signaturen können einen autorisierenden Schlüssel authentifizieren und unbefugte Änderungen an einer Nachricht sichtbar machen. Das macht ML-DSA für Transaktionsautorisierung, Validator- und Bridge-Nachrichten, Software-Releases und langlebige Berechtigungsnachweise relevant.
FIPS 204 lesenWarum eine Blockchain sowohl eine Kryptografie-Karte als auch einen Migrationsplan braucht
Ein KEM signiert keine Transaktion. Eine Signatur schafft nicht automatisch einen vertraulichen Netzwerktransport. ML-KEM und ML-DSA lösen daher unterschiedliche Probleme. Eine Chain kann eines zuerst übernehmen, ohne das andere zu unterstützen, und dieser Unterschied sollte in Dokumentation, Wallet-UX, Protokollspezifikationen und externen Beschreibungen sichtbar bleiben.
Für ML-DSA muss ein Team das Kontomodell, die Adressableitung, Transaktionsserialisierung, das Budget für die Signaturprüfung, Mempool-Verhalten, Archivknoten, Hardware-Wallets, Multisignatur-Richtlinien und sichere Wiederherstellung berücksichtigen. Bei ML-KEM muss es entscheiden, wo verschlüsselte Kanäle oder gespeicherte Geheimnisse hingehören, wie Schlüssel authentifiziert werden, wie Sitzungsschlüssel rotieren und ob während der Umstellung ein Hybridmodus nötig ist.
Die Migrationsleitlinien von NIST besagen, dass seine ersten PQC-Standards jetzt eingesetzt werden können und sollten, während Quantencomputer, die aktuelle Systeme bedrohen, noch Jahre oder Jahrzehnte entfernt sein können. Sie besagen außerdem, dass quantenanfällige Algorithmen bis 2035 aus NIST-Standards zurückgezogen und schließlich entfernt werden. Die Projektseite von NIST macht deutlich, dass dies ein langer Übergang und kein Wechsel über Nacht ist.
„Wir ermutigen Systemadministratoren, sofort mit der Integration in ihre Systeme zu beginnen, da die vollständige Integration Zeit braucht.“
Evidenzkarte: reale Projekte, präzise eingeordnet
Dies ist kein Ranking. Es trennt, was öffentlich dokumentiertes Material stützt, von dem, was es nicht stützt.
| Projekt oder Kategorie | Öffentlich dokumentierte Kryptografie | Evidenzgrad | Schlussfolgerung zu Kyber / Dilithium |
|---|---|---|---|
| Algorand | Falcon-Signaturen in State Proofs und eine durch Falcon autorisierte Mainnet-Transaktion. | Spezifische Implementierung und technischer Mainnet-Bericht. | Ein echter PQC-Signaturmeilenstein, doch Falcon unterscheidet sich von ML-KEM und ML-DSA. Nicht als Unterstützung für Kyber/Dilithium bezeichnen. |
| Quantum Resistant Ledger (QRL) | Die Dokumentation verweist auf die Erstellung von Extended XMSS HyperTree und Einmalsignaturschlüssel. | Projektdokumentation. | Ein Beispiel für eine Chain mit einer anderen Post-Quanten-Signaturfamilie, kein Nachweis einer Bereitstellung von FIPS 203 ML-KEM oder FIPS 204 ML-DSA. |
| QRL-v2.0-Ökosystem | Das QRL-Ökosystem veröffentlicht eine ML-DSA-87-FIPS-204-Signaturbibliothek mit einem „ZOND“-Kontext für QRL-v2.0-Anwendungen. | Bibliotheksnachweis, keine protokollweite Mainnet-Behauptung. | Spezifische ML-DSA-Unterstützung ist auf Bibliotheksebene dokumentiert. Die Bibliotheksseite belegt weder ML-KEM noch eine mainnetweite ML-DSA-Validierung. |
| Cellframe | Die Einführung besagt, dass die Plattform Crystal Dilithium, Kyber 512 und Falcon verwendet. | Offizielle Projektdokumentation mit begrenzten Implementierungsdetails. | Ein direkter projektbezogener Verweis auf Kyber und Dilithium. Den behaupteten Umfang nur als von Cellframe dokumentiert behandeln, bis Code-, Parameter- und Aktivierungsdetails unabhängig geprüft sind. |
| QANplatform | Die Dokumentation besagt, dass ML-DSA über QAN XLINK zum Gegenzeichnen von Konten verwendet wird. | Offizielle Projektdokumentation, aber kein benannter ML-DSA-Parametersatz oder Mainnet-Transaktionsnachweis auf der zitierten Seite. | Spezifischer ML-DSA-Verweis und Design für eine Signaturmigration. Die zitierte Dokumentation behauptet keine Unterstützung für ML-KEM oder Kyber. |
| Hyperledger-basierte Forschung | Forschungsarbeiten modellieren oder prototypisieren die Integration von Kyber und Dilithium in permissionierten Blockchain-Konfigurationen. | Akademischer Machbarkeitsnachweis. | Nützlich für die technische Bewertung, aber kein Beleg, dass ein unverändertes Hyperledger Fabric oder ein anderes Produktionsnetzwerk ML-KEM oder ML-DSA protokollweit ausliefert. |
| EVM- und große Layer-1-Ökosysteme | Im breiteren Entwicklerökosystem finden sich Forschung, Diskussionen über Account-Abstraction, Kryptografiebibliotheken und vorgeschlagene Precompiles. | Abhängig von Vorschlag und Repository. | Eine Bibliothek oder ein Vorschlag ändert die Konsensvalidierung nicht. Vor einer Unterstützungsbehauptung den tatsächlichen Client-Release und die Chain-Aktivierung prüfen. |
| Autheo | Eine Roadmap zu Kyber, Dilithium und Falcon befindet sich in Entwicklung. | Roadmap, kein Live-Schutz. | Die Post-Quanten-Arbeit ist noch nicht in das Live-System eingebunden. Sie darf nicht als aktuelle Chain-Sicherheit beschrieben werden. |
Algorand liefert das klarste Abgrenzungsbeispiel. Sein Falcon-1024-Mainnet-Pfad nutzt eine Logic Signature und den AVM-Opcode falcon_verify. Der veröffentlichte Bericht beschreibt Falcon-1024-Signaturen von rund 1.280 Byte, öffentliche Schlüssel von 1.793 Byte und State Proofs alle 256 Runden. Das ist ein starker Nachweis für einen Falcon-Anwendungsfall, aber kein Grund, Falcon in einer Aussage über Kyber und Dilithium durch ML-KEM oder ML-DSA zu ersetzen.
QRL bietet einen zweiten nützlichen Vergleich. Seine Dokumentation behandelt Extended XMSS HyperTree und Einmalsignaturschlüssel, was zeigt, dass „Post-Quanten-Blockchain“ kryptografische Designs jenseits gitterbasierter NIST-Standards meinen kann. Die QRL-Dokumentation belegt keine Unterstützung für ML-KEM oder ML-DSA, daher behauptet dieser Leitfaden dies nicht.
Es gibt engere NIST-Algorithmusverweise, die es zu verfolgen gilt. Die veröffentlichte ML-DSA-87-Bibliotheksdokumentation des QRL-Ökosystems nennt FIPS 204 und eine ML-DSA-87-Signatur von 4.627 Byte, bleibt jedoch ausdrücklich ein Nachweis auf Bibliotheksebene und keine Behauptung zur Mainnet-Validierung. Die offizielle Einführung von Cellframe besagt, dass Crystal Dilithium, Kyber 512 und Falcon verwendet werden. Das ist eine direkte Projektbehauptung für beide Algorithmen, doch die zitierte Einführung liefert keinen Parametersatz oder eine Aktivierungsspezifikation. Leser sollten daher Code und Protokoll-Releases prüfen, bevor sie eine weitergehende Schlussfolgerung ziehen.
QANplatform liefert ein separates, auf ML-DSA fokussiertes Beispiel. Die Dokumentation zur quantenresistenten Sicherheit besagt, dass ML-DSA über QAN XLINK zum Gegenzeichnen von Konten verwendet wird, und beschreibt ein in Go implementiertes, migrationsorientiertes Signaturschema. Dieselbe Seite nennt weder einen ML-DSA-Parametersatz noch eine Produktions-Transaktion oder Unterstützung für ML-KEM oder Kyber. Deshalb führt dieser Leitfaden QANplatform unter spezifischer ML-DSA-Dokumentation und nicht als bestätigte Bereitstellung beider Algorithmen.
So prüfen Sie eine Behauptung zur Unterstützung von Kyber oder Dilithium
1. Primitive bestimmen
Nennt die Behauptung ML-KEM oder ML-DSA, den Parametersatz und die genaue Funktion? Ein allgemeiner Verweis auf „NIST PQC“ reicht nicht aus.
2. Ausführungsgrenze finden
Finden Sie Transaktionstyp, Knotenkanal, Wallet, Identitätsnachweis, State Proof, Bridge oder API, an der Verifikation oder Verkapselung stattfindet.
3. Netzwerkstatus bestätigen
Prüfen Sie Release Notes, Quellcode, Protokollversionen, Testvektoren und eine Testnet- oder Mainnet-Aktivierung. Trennen Sie Opt-in von verpflichtendem Verhalten.
4. Kosten messen
Erfassen Sie Signatur- und Public-Key-Größen, Verifikationslatenz, Speicherverbrauch, Gebühreneffekt, Bandbreitenwirkung und Unterstützung auf Mobil- oder Hardware-Geräten.
5. Migrationsmechanik prüfen
Bewerten Sie Konto-Upgrades, Schlüsselrotation, Multisig, Wiederherstellung, Abwärtskompatibilität, Bridge-Interoperabilität und die Stilllegung alter Kryptografie.
6. Unabhängige Nachweise prüfen
Suchen Sie reproduzierbare Tests, Audits, Standardkonformität, Issue-Tracking und eine klare Beschreibung offener Risiken statt nur nach Werbetext.
Wo ML-KEM und ML-DSA in eine Blockchain-Architektur passen könnten
ML-DSA hat die offensichtlichste blockchainnahe Rolle, weil Blockchains bereits von Signaturen abhängen. Eine künftige Integration könnte eine Kontotransaktion, eine Validator-Stimme, eine Bridge-Bescheinigung, ein Oracle-Update, eine Administratoraktion oder einen Software-Release autorisieren. Jeder Einsatz hat eine andere Verifikationsfrequenz und Fehlerart. Eine Signatur, die in einer Release-Pipeline funktioniert, kann für einen Transaktionspfad mit hohem Volumen zu groß oder zu langsam sein.
ML-KEM gehört meist auf eine andere Ebene. Es kann zwei Parteien helfen, ein Geheimnis für verschlüsselten Transport oder gespeichertes Material aufzubauen. Das kann für eine Wallet mit einer Dienstverbindung, private Knoten-zu-Knoten-Kommunikation, verschlüsselte Off-Chain-Daten, den Austausch eines Identitätsnachweises oder einen Validator-Betriebskanal relevant sein. Es verbirgt öffentliche Ledger-Daten nicht selbst und beweist nicht, dass ein Wallet-Inhaber eine Übertragung autorisiert hat.
Adressdesign ist eine häufige Quelle für Verwirrung. Wenn eine Kontoadresse an einen öffentlichen Verifikationsschlüssel gebunden ist, kann ein Post-Quanten-Signaturschema eine neue Adressfamilie, ein gekennzeichnetes Transaktionsfeld oder eine Account-Abstraction-Ebene verlangen, die zum richtigen Verifizierer leitet. Wallets müssen dann den Sicherheitsmodus klar anzeigen, unbeabsichtigte Herabstufungen vermeiden und Nutzer davor schützen, eine klassische Adresse wiederzuverwenden, wenn die Anwendung ein Post-Quanten-Konto erwartet.
Smart-Contract-Netzwerke brauchen ebenfalls eine explizite Entscheidung zur Verifikation. Ein natives Client-Feature, ein Opcode der virtuellen Maschine, ein Precompile und eine Vertragsbibliothek haben sehr unterschiedliche Kosten- und Vertrauenseigenschaften. Native Integration kann effizient sein, verlangt aber ein Protokoll-Release. Eine Vertragsimplementierung kann leichter zu testen sein, aber praktische Gas- oder Ausführungsbudgets überschreiten. Der dokumentierte Falcon-Verifikationspfad von Algorand zeigt, warum der Ort des Verifizierers Teil jeder Behauptung sein sollte.
Die passende Architektur kann daher gestuft werden. Beginnen Sie mit Inventar- und Software-Signatursystemen, schaffen Sie Testvektoren und reproduzierbare Benchmarks, unterstützen Sie gegebenenfalls Opt-in-Konten oder -Kanäle und entscheiden Sie dann, ob ein Konsens-Upgrade gerechtfertigt ist. Offen zu legen, was klassisch bleibt, ist eine Stärke. Dadurch können Integratoren Restrisiken einschätzen, ohne ein gezieltes Experiment mit pauschaler Post-Quanten-Sicherheit zu verwechseln.
Autheos Rolle in diesem Übergang
Autheo entwickelt seine Roadmap zu Kyber, Dilithium und Falcon für künftige Protokoll-, Identitäts- und Schlüsselverwaltungsarbeit. Diese Arbeit ist noch nicht in das Live-System eingebunden, und es wäre unzutreffend zu sagen, dass diese Algorithmen Autheo derzeit absichern. Staking und Transaktionsgebühren sind heute live; die Post-Quanten-, TheoID-, Compute-, Storage-, KI-Inferenz- und THEO-AI-Schichten befinden sich weiterhin in Entwicklung.
Jede künftige Implementierung sollte nach denselben Kriterien bewertet werden wie bei jeder anderen Chain: exakter Algorithmus und Parametrisierung, kryptografische Grenzen, Migrationspfad, reproduzierbare Tests, unabhängige Prüfung, Betriebskosten und klare Offenlegung dessen, was noch nicht migriert ist. Eine Roadmap gibt dieser Arbeit eine Richtung. Sie ersetzt keine Nachweise.
Autheo läuft auf Proof of Autheo, einem Hybrid PoA/PoS-Modell. Erfahren Sie mehr über die aktuelle Konsensarchitektur getrennt von der künftigen Post-Quanten-Entwicklung.
Verwandte Autheo-Ressourcen
Leitfaden zu Post-Quanten-Blockchains
Verstehen Sie das breitere Bedrohungsmodell, den Migrationsrahmen und die Algorand-Fallstudie.
Algorand-Vergleich
Vergleichen Sie Architekturen und prüfen Sie Projektverweise.
Ethereum-Vergleich
Ein Basisvergleich für den Kontext der kryptografischen Migration von Layer 1.
FAQ-Hub
Durchsuchen Sie kanonische Autheo-Antworten für Entwickler und Unternehmen.
Vollständiger Leitfaden: Was ist Autheo?
Lesen Sie den grundlegenden Leitfaden zu Autheos geplanter einheitlicher Architektur.
Ihren ersten Smart Contract bereitstellen
Beginnen Sie mit dem Builder-Workflow und Entwicklungsressourcen.
Was ist Layer 0?
Prüfen Sie das Architekturmodell von Layer 0 und Layer 1.
Sicherheitsprogramm
Prüfen Sie Kontaktinformationen für Sicherheit und verantwortungsvolle Offenlegung.
FAQ zu Kyber- und Dilithium-Blockchains
Fordern Sie Nachweise für jede kryptografische Behauptung
Die richtige Frage ist nicht, ob ein Projekt sich als quantensicher bezeichnet. Sie lautet: wo, wie und mit welchen unabhängig überprüfbaren Nachweisen?
Autheo für Builder entdecken