Autor des Artikels: Mysten Labs, Kostas Chalkias und Mahdi Sedaghat

https://www.sui.io/blog/suis-post-quantum-signature-schemes

Zusammenfassung der wichtigsten Punkte

• Sui setzt auf ML-DSA-65 aus NIST Level 3 und nicht auf ein kostengünstigeres Sicherheitsniveau mit weniger Reserve. Heutzutage kann KI-unterstützte Kryptanalyse bereits einige Gitterkryptosysteme angreifen, die jahrelang von Menschen begutachtet wurden. Die Mehrkosten durch eine höhere Sicherheitsreserve sind dabei nahezu zu vernachlässigen: Die Verifikationsleistung von ML-DSA-65 ist praktisch mit der von Ed25519 vergleichbar.

• Zwei Ansätze aus zwei unterschiedlichen mathematischen Grundlagen. Die SLH-DSA-Brieftasche läuft in Move, nicht auf der Protokollebene. Daher wirkt sich ein möglicher Durchbruch bei Gitterkryptografie nicht auf den hashbasierten Sicherheitspfad aus. Gleichzeitig kann Sui sich an Änderungen externer Standards anpassen, ohne ein Protokoll-Upgrade durchführen zu müssen.

• Bestehende Nutzer sind nicht betroffen. Der Private Key bleibt weiterhin 32 Byte, daher muss sich die Wallet-Backup-Methode nicht ändern. Post-Quantum-Konten nutzen den freiwilligen Auswahlmodus, und Address Aliases erlauben bestehenden Konten, den autorisierten Schlüssel auf einen post-quantum Schlüssel umzustellen – bei gleichbleibender Adresse und Vermögenswerten.

In dem kürzlich veröffentlichten Beitrag (Sui is preparing for the quantum era) haben wir die Entwicklungsrichtung für Sui im Bereich Post-Quantum-Security vorgestellt: native Kontobestätigung mit ML-DSA-65, Schutz für High-Value-Tresore mit SLH-DSA-SHA2-128s und gleichzeitig ein Migrationspfad, mit dem bestehende Adressen und Wiederherstellungssätze erhalten bleiben.

Dieser Artikel erklärt den dahinterliegenden „Warum“-Grund und führt aus Sicht von Kryptografen in die Logik dieser Entscheidungen ein. Warum ML-DSA-65 statt eines günstigeren Sicherheitslevels? Warum haben wir es trotz kleinerer Falcon-Signaturen nicht gewählt? Warum wurde SLH-DSA in Smart Contracts platziert und nicht auf Protokollebene? Warum haben wir nicht einfach vorhandene Libraries genutzt, sondern stattdessen selbst einen Rust-Wrapper geschrieben? Und was haben wir dabei gelernt? Wenn du nach dem Lesen des vorherigen Artikels wissen möchtest, warum diese Entscheidungen technisch so gefallen sind, dann ist dieser Artikel die Antwort.

Die wirklich schwierigen Entscheidungen liegen nicht darin, welche Algorithmus-Variante man auswählt. NIST hat dieses Problem vor Jahren im Wesentlichen bereits gelöst. Für Signaturen gibt es im Grunde nur zwei Kandidatenbereiche: ML-DSA (FIPS 204) und SLH-DSA (FIPS 205). Der eigentliche Aufwand steckt danach in einer ganzen Reihe weiterer Fragen: Welches Sicherheitslevel wird gewählt? Welche Implementierung wird verwendet? Wie wird der Code verifiziert? Wie geht man mit bereits bestehenden Schlüsseln um? Und welche technisch verlockenden Abkürzungen entscheiden wir am Ende dagegen – und warum?

Zuerst stelle ich kurz unser Hintergrund ein. Unsere Forschung zu post-quantum Systemen ist älter als Sui selbst: Bereits 2017 brachten wir in R3 Corda ein produktionsreifes, stateless post-quantum Design auf den Markt – das erste stateless, mehrfach nutzbare ant-quantum Signaturdesign im Bereich verteilter Ledger. In den folgenden Jahren arbeiteten wir mit Mike Hearn zusammen an post-quantum Kryptostrukturen, die sich für Blockchains eignen. Außerdem bauten wir bei Meta Winterfell – den ersten Open-Source STARK-Beweiser – sowie Forschung zu PQ-EdDSA, HashWires und Truncator.

Für die konkrete Migrationsstrategie für Sui haben wir bereits seit dem April 2025 veröffentlichten Beitrag (How to Ensure Sui Security in the Quantum Computing Era) geplant – unter anderem in Bezug auf Signaturen, Hashes, Verschlüsselung und Zero-Knowledge-Proofs. Unten stellen wir den Signatur-Teil vor; die zugehörigen Entscheidungen sind mittlerweile finalisiert.

Präzise Bedrohung definieren

Der Shor-Algorithmus kann RSA und elliptische Kurvenkryptografie direkt knacken. Der Grover-Algorithmus bringt bei Hash-Funktionen nur eine quadratische Beschleunigung; durch Erhöhung der Hash-Ausgabelänge lässt sich diese Auswirkung ausgleichen. Daher konzentriert sich das Quantenrisiko bei Blockchains nahezu vollständig auf Signaturen – nicht auf Hashes.

Das Besondere an Blockchains ist nicht der Algorithmus selbst, sondern die Art, wie der Public Key offengelegt wird. In den meisten Systemen befindet sich der Public Key hinter einer gewissen Zugriffsschranke; Angreifer müssen zuerst das System überwinden, und die Countdown-Zeit für den Angriff beginnt erst dann wirklich. Auf der Chain ist der Public Key jedoch dauerhaft öffentlich, sobald ein Konto seine erste Transaktion abschließt. Ähnlich wie bei „Jetzt sammeln, später entschlüsseln“ muss ein Angriff auf Signaturen nicht einmal heute bereits über Quantenhardware verfügen – es reicht, Daten zu speichern und geduldig zu warten: Heute den Public Key sammeln, und wenn die Quantenhardware in der Zukunft reif ist, Signaturen fälschen. Dieses Sammelfenster ist bereits seit Jahren geöffnet, und die Prognosen zur Entwicklung der Quanten-Rechenleistung verlaufen in die gleiche Richtung: von einer Schätzung der benötigten Ressourcen zur Zerlegung eines 2.048-Bit-RSA-Keys, die von rund 20 Millionen Quantenbits im Jahr 2019 auf weniger als 1 Million im Jahr 2025 zurückging. Jede Korrektur bedeutet: Die benötigten Maschinen werden kleiner und günstiger – statt teurer.

Dadurch wird auch die Migrationsfrist neu definiert. In einer am Juni 2026 veröffentlichten Executive Order Nr. 14412 fordert die USA die Bundesbehörden auf, die Migration der Post-Quantum-Schlüsselherstellung bis spätestens Dezember 2030 abzuschließen und die Migration der digitalen Signaturen bis spätestens Dezember 2031 zu vollenden – also deutlich früher als der Migrationszeitplan von 2035 des NIST, der sich noch im Entwurfsstadium befindet. Für On-Chain-Schlüssel ist die reale Frist sogar noch früher, weil das Risiko sich über die Zeit in die Vergangenheit aufsummiert: Ein Schlüssel, der am ersten Tag öffentlich ist, ist bereits ab dem ersten Tag exponiert – statt erst zu dem Zeitpunkt, wenn die Stichtage eintreffen.

Warum ML-DSA-65 statt ML-DSA-44

NIST teilt Post-Quantum-Optionen in fünf Sicherheitslevels ein. Jedes Level entspricht einem konkreten Brute-Force-Benchmark – nicht einer abstrakten Anzahl von Sicherheitsbits:

• Level 1: Der Schwierigkeitsgrad entspricht mindestens dem Wiederherstellen eines AES-128-Schlüssels

• Level 3: Entspricht AES-192

• Level 5: Entspricht AES-256

Geradzahlige Levels werden nach Hash-Kollisionen definiert: Level 2 entspricht SHA-256, Level 4 entspricht SHA-384.

ML-DSA bietet drei Parameter-Sets:

ML-DSA-44: Level 2

ML-DSA-65: Level 3

ML-DSA-87: Level 5

Ein Sicherheitslevel steht für die Sicherheitsuntergrenze unter den aktuell bestbekannten Angriffsmethoden. Daher beantwortet die Wahl des Levels im Kern eine Frage: Wenn die fortschrittlichsten zukünftigen Angriffsmethoden sich weiter verbessern, wie viel Sicherheitsreserve müssen wir dann noch übrig lassen?

Sui trifft die endgültige Entscheidung, ML-DSA-65 mit Level 3 zu einem Protokoll-nativen Signaturschema zu aggregieren, statt das kostengünstigere ML-DSA-44.

Einer der wichtigen Gründe ist außerdem ein Angriff auf das HAWK-Signaturschema, den Anthropic kürzlich entdeckt hat. HAWK ist ein gitterbasiertes Schema, das intensiv erforscht wurde und einer großen Menge an kryptografischem Security-Review unterzogen wurde. Wichtig ist hervorzuheben: HAWK und ML-DSA basieren auf unterschiedlichen Gitterproblemen – daher kann ein Angriff auf HAWK nicht direkt auf ML-DSA übertragen werden. Aber das, worauf es hinweist, ist wirklich relevant: KI-gestützte Kryptoanalyse hat bereits damit begonnen, Probleme zu finden, die menschliche Prüfer über Jahre hinweg nicht entdeckt haben.

Das verändert unsere Bewertung, wie viel Sicherheitsreserve wir für kryptografische Annahmen auf Gitterbasis vorhalten sollten. Level 1 lässt bei Sicherheitsabschätzungen weniger Spielraum, wenn sich diese ändern; Level 3 bietet dagegen größere Puffer – und es hat sich gezeigt, dass die Kosten für diese zusätzliche Sicherheitsreserve sehr gering sind.

Außerdem gibt es noch zwei nebensächliche Gründe. Erstens haben auch Chrome und Cloudflare sich für Level 3 entschieden – in einer Vielzahl der derzeit bereits geschützten post-quantum Schlüssel-Austausch-Implementierungen. Daher gibt es für dieses Level bereits mehr praktische Deploy-Erfahrung. Zweitens passt Level 3 auch besser zu den Sicherheitsannahmen dieser Institutionen, wenn wir über Mechanismen zur Schlüsselherstellung mit regulierten Finanzbranchen diskutieren.

Auch Hardware-Unterstützung ist für uns ein wichtiger Faktor. Wir haben FIPS-204-Kompatibilität direkt gegen HSM- und Hardware-Wallet-Anbieter-SDKs verifiziert. Wir haben außerdem ML-DSA auf sehr stromsparenden DePIN-Geräten getestet – das sind die begrenzten CPU- und RAM-Umgebungen, denen NFC-Post-Quantum-Wallets begegnen, und genau dort zeigt sich zuerst, wenn ein Algorithmus zu schwer ist.

Auch das gesamte Ökosystem bewegt sich in eine ähnliche Richtung. Ledger hat kürzlich bereits in seinem SDK eine erste Unterstützung für offizielles ML-DSA (FIPS 204) ergänzt und ist dabei bis auf Byte-Ebene mit dem NIST-Standard kompatibel. Wir haben außerdem verifiziert, dass Ledger und unsere Implementierung sich gegenseitig signaturfähig austauschen können.

Währenddessen überwachen wir weiterhin kontinuierlich den Stand der Kryptoanalyse gegen ML-DSA. Diese fortwährende Ungewissheit ist ein Grund dafür, dass wir SLH-DSA priorisiert als Smart-Contract-Lösung herausbringen und für High-Value-Tresore empfehlen: Seine Sicherheit hängt von Hash-Funktionen ab, nicht von Gitterkryptografie. Daher bleibt SLH-DSA auch dann unberührt, wenn es in Zukunft Durchbrüche in der Gitterkryptografie geben sollte, die die Sicherheitsabschätzungen für ML-DSA beeinflussen könnten.

Warum wurde nicht Falcon gewählt?

Ein weiterer gitterbasierter Kandidat ist Falcon (FN-DSA, d. h. der zukünftige FIPS 206). Sein größter Vorteil ist, dass Signaturen kleiner sind. Unter Level 1 beträgt die Signaturgröße von FN-DSA-512 nur 666 Byte, während die Signaturgröße von ML-DSA-65 auf Level 3 3.309 Byte beträgt.

Trotzdem haben wir Falcon nicht ausgewählt, unter anderem aus folgenden Gründen:

• Kein Level 3. Falcon bietet nur Level 1 und Level 5 (jeweils FN-DSA-512 und FN-DSA-1024): Entweder man wählt das eben erwähnte Level 1 mit weniger Reserve, oder man zahlt den Preis von Level 5, um einen größeren Sicherheits-Puffer zu erhalten – letzteres würde die Kennzahlen etwa verdoppeln.

• Standardisierung noch nicht abgeschlossen. FIPS 206 ist derzeit noch nicht finalisiert; im Gegensatz dazu ist FIPS 204 seit 2024 bereits offiziell finalisiert.

• Fehlende standardisierte Ableitung von Seed zu Key. Das würde die derzeit mögliche Eigenschaft zerstören, dass Wallet-Backups weiterhin den 32-Byte-Seed beibehalten können.

• Sampling einer Gaußverteilung mittels Floating Point. Bei Falcon wird im Signaturprozess eine Floating-Point-FFT zur diskreten Gauß-Sampling-Berechnung benötigt, und dieses Mechanismus gilt allgemein als deutlich schwieriger, korrekt umzusetzen als jede Implementierung, die ML-DSA benötigt. Im Vergleich dazu nutzt ML-DSA durchgehend Integer-Operationen.

• Schwerere Anforderungen für sichere Implementierungen. Bei einem Gauß-Sampling-Mechanismus müssen konstante Laufzeit sichergestellt, Fault Attacks und Cache-Attacks abgewehrt werden und zudem die Qualität der Zufallszahlen garantiert werden – das stellt höhere Implementierungsanforderungen.

• Side-Channel-Schutz ist schwieriger. Da Falcon Gauß-Sampling und FFT-Operationen beinhaltet, gilt es allgemein als schwieriger als ML-DSA, robuste Sicherheit gegenüber Timing-Attacks, Cache-Attacks und Fault-Attacks zu erreichen.

• Verifikationsgeschwindigkeit. Bei höheren Sicherheitslevels ist die Verifikationsgeschwindigkeit von Falcon langsamer als die Ergebnisse, die wir für ML-DSA gemessen haben. Konkret: Auf derselben Maschine beträgt die Verifikationszeit für FN-DSA-1024 49,8 Mikrosekunden, während ML-DSA-65 nur 23,2 Mikrosekunden benötigt. Das bedeutet: Bei ausreichend Sicherheitsreserve ist die Verifikationsgeschwindigkeit des Falcon-Parameter-Sets ungefähr doppelt so langsam wie die des von uns gewählten Schemas.

• Hardware-Ökosystem. Viele HSM-Hersteller, Smartcards, TPMs und Secure Elements unterstützen bevorzugt ML-DSA: Es wurde früher standardisiert, lässt sich leichter implementieren und ist außerdem eine Lösung, die von Unternehmenskunden besonders stark nachgefragt wird. Nach den Rückmeldungen, die wir erhalten haben, verbessert sich die Hardware-Unterstützung für Falcon zwar, aber die Verbreitung liegt noch immer unter der von ML-DSA.

• Ganz wichtig ist auch das Ökosystem und die Tools. Aktuell ist ML-DSA in Kryptobibliotheken, SDKs, Testvektoren, Compliance-Paketen sowie in zertifizierten Implementierungen deutlich reifer. Das senkt das Risiko bei der Engineering-Umsetzung, insbesondere wenn es als protokollnative Funktion eingesetzt wird.

Daher reicht eine kleinere Signaturgröße nicht aus, um diese Nachteile auszugleichen.

Warum läuft SLH-DSA auf Move und nicht auf Protokollebene

Für hochwertige Assets stellen wir hashed-basiertes SLH-DSA-SHA2-128s (FIPS 205) über Move Smart-Contract-Tresore bereit, statt es als protokollnative Signaturlösung zu nutzen. Das ist nicht, weil wir SLH-DSA nicht vertrauen. Im Gegenteil: Hash-basierte Kryptografie ist in beiden Systemen die besser verstandene Kategorie, und SHA-256 wird bereits weit verbreitet eingesetzt. Einige der Hardware-Wallet-Teams, mit denen wir gesprochen haben, bevorzugen sogar eher hash-basierte Ansätze, weil Ingenieure sie tiefer verstehen.

Wir bringen es aus drei Gründen in den Smart Contract:

• Kostenprofil. Die Verifikationskosten von SLH-DSA liegen deutlich höher als die von Ed25519, und zudem ist die Signaturgröße größer; durch Caching lässt sich der Mehraufwand nicht effektiv reduzieren. Bei ML-DSA ist der öffentliche Schlüssel ein wiederverwendbarer Teil – daher kann Caching spürbare Vorteile bringen; bei SLH-DSA gibt es keinen vergleichbaren Optimierungsspielraum.

• Risiko durch Standardänderungen. Bitcoin, Ethereum und die nächste Runde von NIST-Standards werden sich sehr wahrscheinlich am Ende auf eine kleinere Menge an Signaturschemata einigen, als es heute der Fall ist. Unabhängig davon, welches Schema Bitcoin und Ethereum-Communities am Ende wählen – einschließlich der verschiedenen hash-basierten Schemata, die derzeit diskutiert werden – möchten wir schnell Kompatibilität herstellen können. Die Brücke zwischen Sui und Ethereum sowie Hashi für Bitcoin machen diese Anforderung besonders realistisch: Wenn wir die Implementierung innerhalb von Verträgen vornehmen, dann muss ein Bitcoin-Wallet, das post-quantensichere Kryptografie auf Sui unterstützt, keine neue Sui-Kernversion veröffentlichen. Wenn wir stattdessen native Schemata verwenden, kann bei jeder Änderung der externen Zielstandards jeweils ein Protokoll-Upgrade nötig werden.

• Implementierungsumfang. Die Implementierung von SLH-DSA in Move betrifft vor allem merklebaumbezogene Operationen. Im Vergleich dazu, dass man stattdessen einen zusätzlichen nativen Authenticator hinzufügt, ist der Implementierungsumfang kleiner und der Code klarer und leichter verständlich. Außerdem kann es ohne Hard Forks oder Protokoll-Upgrades in Produktion gehen, weil die erforderliche Byte-Verarbeitung und Hash-Primitiven bereits in der Move-Sprache vorhanden sind.

Diese beiden Lösungen basieren auf unterschiedlichen mathematischen Systemen – und genau das ist der Kern der Designentscheidung. Wenn die Sicherheitsannahme der Gitterkryptografie gebrochen wird, wirkt sich das nicht auf den hash-basierten Sicherheitsweg aus – und umgekehrt auch nicht.

Für Konten mit höchstem Wert lässt Sui es außerdem zu, dass seine bestehenden 2-of-2 Multi-Signature-Mechanismen noch weiterhin die Nutzeroption bieten, für die Autorisierung einer Transaktion gleichzeitig eine traditionelle Signatur und eine post-quantum Signatur einzufordern. Damit wird keine der beiden Varianten allein zum Single Point of Failure eines Sicherheitssystems. Das ist auch genau die Position, die kürzlich in der von Bernstein angestoßenen Diskussion für ein hybrides Sicherheitsmodell vertreten wurde.

Beide Lösungen folgen den von NIST standardisierten Post-Quantum-Kryptografiealgorithmen (ML-KEM, ML-DSA, SLH-DSA) sowie der von CISA, NSA und NIST gemeinsam erstellten Quantum-Secure-Readiness-Roadmap.

Leistungstests

Diese Entscheidungen hängen am Ende aber alle vom Kostenfaktor ab. Wir haben Tests mit fastcrypto auf dem Apple M2 Max durchgeführt.

Hier sind wirklich zwei Punkte entscheidend.

Die Verifikationsleistung liegt nahezu auf dem Niveau von Ed25519 und ist in der Praxis sogar geringfügig besser – daher steigen die CPU-Kosten, die ein Verifizierungsknoten pro Signatur aufwenden muss, nicht. Das ist sehr wichtig, weil Sui zu den weltweit schnellsten L1s gehört und selbst nach der Post-Quantum-Migration diesen Vorsprung weiter halten muss. Der wirklich entscheidende Kennwert ist die Verifikationskosten: Die Berechnungskosten entstehen an unterschiedlichen Stellen in der Prozesskette. Schlüsselgenerierung und Signierung erfolgen für jede Transaktion außerhalb der Chain – auf dem Gerät des Signierenden; Verifikation hingegen muss von jedem Verifizierungsknoten für jede Transaktion durchgeführt werden. In absoluten Zahlen betrachtet ist die Signierung zwar tatsächlich langsamer, aber auf Client-Geräten dauert sie nur etwa 66 Mikrosekunden – selbst im Browser sind es nur Millisekunden; Nutzer nehmen diesen Unterschied praktisch nicht wahr.

Der Private Key bleibt weiterhin 32 Byte, weil er im Grunde ein Seed ist. Das Wallet kann weiterhin auf genau die gleiche Weise wie heute Backups und Wiederherstellungen durchführen; die neuen Schlüssel werden über einen neuen standardisierten Ableitungspfad aus demselben Wiederherstellungssatz des Nutzers generiert.

Der wirklich zu zahlende Preis ist die Datenmenge: Für jede Transaktion steigen die zugehörigen Daten ungefähr auf das 50-Fache. Das ist der Preis, den die gesamte Branche zahlen muss, um Quantenfestigkeit zu erlangen, und auch unser aktueller Fokus bei Optimierungen. Für Sui gibt es jedoch zwei Faktoren, die dieses Problem abmildern: Erstens ist die Obergrenze für die Transaktionsgröße bei Sui bis zu 128 KB, sodass im Vergleich zu Blockchains mit strengeren Transaktionsgrößenlimits mehr Platz verfügbar ist. Zweitens haben wir bereits zuvor Lösungen mit großen Signaturen produktiv eingesetzt und betrieben, einschließlich Multi-Signature und zkLogin. Außerdem erlaubt das programmierbare Transaktions-Block (PTB), dass eine Signatur mehrere Aktionen gleichzeitig autorisiert; dadurch ist der durchschnittliche Zusatzaufwand pro Aktion tatsächlich niedriger als das, was sich rein aus der Größe einer einzelnen Signatur ableiten ließe. Zukünftig kann man außerdem ein ähnliches Public-Key-Caching wie bei aktuellem zkLogin nutzen: Nutzer müssen ihren Public Key nur einmal einreichen; danach müssen die Transaktionen nur noch Signaturen senden. Diese Funktion wird jedoch nicht im ersten Release aktiviert. Wir möchten, dass die erste Implementierung relativ konservativ bleibt und diese Optimierung erst später – nach gründlicher Abwägung – schrittweise aktiviert wird.

Außerdem gilt: Die oben genannten Daten repräsentieren nur eine bestimmte Testkonfiguration. Für einen umfassenderen und strengeren Performance-Report müssen außerdem der Rust-Ausführungspfad auf Verifizierungsknoten-Seite, eine typische Entwicklerkonfiguration und Signaturen im Browser über den TypeScript-Stack abgedeckt werden. Wir planen, später vollständigere Testdaten zu veröffentlichen. Für einen umfassenderen Vergleich der NIST-Kandidaten-Signaturschemata siehe nist-sigs-zoo.

Außerdem erleichtern Sui-Remora-Forschung zur Ausführungserweiterung und die damit verbundenen Probleme bei der Durchsatzskalierung die Behandlung im Verlauf der Post-Quantum-Migration. Diese beiden Forschungsrichtungen wurden von Anfang an bewusst gemeinsam vorangetrieben.

Implementierungsweise – und warum wir uns dafür entschieden haben, es selbst zu machen

Beinahe jede Programmiersprache hat große Krypto-Bibliotheken, und darin ist ML-DSA bereits enthalten – daher scheint es zunächst die naheliegendste Wahl zu sein, einfach eine fertige Bibliothek zu übernehmen. Aber wir haben einen anderen Weg gewählt: Wir haben mysten-mldsa-native-rs entwickelt – ein leichtgewichtiges Rust-Wrapper-Tool, das auf mldsa-native basiert. mldsa-native ist eine kompakte, formal verifizierte ML-DSA-Implementierung, die als Projekt im pq-code-package-Programm unter der Linux Foundation gepflegt wird. Es nutzt denselben Kern wie mehrere gängige Krypto-Bibliotheken wie aws-lc, ohne die restlichen Komponenten großer Bibliotheken mitzubringen.

Warum machen wir das so? Der Schlüssel liegt darin, dass dieser Code in der Konsens-Ausführungspfade liegt. Jeder Verifizierungsknoten muss den Verifikationscode für jede Transaktion ausführen – daher möchten wir den Implementierungsumfang so weit wie möglich einschränken, damit der Code lesbar und auditierbar bleibt und gleichzeitig keine Optionen bereitgestellt werden, die falsch konfiguriert werden könnten. Diese Kapselung bietet nur ein einziges Muster: den FIPS-204-Standardmodus, mit hedged signing (abgesichertes Signieren) – also verwendet jede Signatur neue Zufallswerte, um die Widerstandsfähigkeit gegen Fault Attacks und Probleme bei wiederverwendetem Zufall zu erhöhen. Sie enthält selbst keinen Zufallszahlengenerator, sodass jede Operation in der Testumgebung reproduzierbar ist. Der Private Key hat außerdem nur eine einzige Serialisierungsform, nämlich ein 32-Byte-Seed. So kann das Wallet weiterhin exakt auf die gleiche Art wie bisher Backups und Wiederherstellungen durchführen.

Wie oben bereits erwähnt, ist unsere Implementierungsgeschwindigkeit sehr hoch. Das liegt vor allem daran, dass es bei Upstream bereits verifizierte Assembly-Implementierungen für Apple/ARM und x86-Serverhardware gibt. Das System wählt zur Laufzeit automatisch die passende Implementierung für die jeweilige Maschine aus, sodass am Ende dieselbe Binary-Datei in einer gemischten Umgebung aus Verifizierungsknoten-Hardware korrekt läuft. Unabhängig davon, welche Low-Level-Implementierung verwendet wird, sind die erzeugten Signaturen vollständig identisch. Der Unterschied liegt nur in der Performance: Der Assembly-Backend läuft etwa 2,5-mal schneller als eine portable C-Implementierung.

Ein selten diskutierter Schwachpunkt

Die wirklich gefährliche Stelle in neuer Kryptografie ist oft nicht die Mathematik, sondern der Code – und die hektische Implementierung.

Dieses Jahr wurde ein führender STARK-Beweiser offengelegt, der eine Schwachstelle in der Korrektheit (Soundness) besitzt: Ein bestimmter Wert, dem der Verifizierungsknoten vertraut, ist nicht wirklich an das Proof-transcript gebunden. Dadurch kann ein böswilliger Beweiser einen Proof mit falscher Behauptung fälschen, und der Verifizierungsknoten akzeptiert ihn trotzdem. Diese Schwachstelle existierte seit 2024 im Open-Source-Code, überstand externe Audits und formale Verifikation – und wurde dennoch nicht entdeckt. Schließlich wurde sie im Juni 2026 von einem AI-Audit-Tool gefunden; zum Glück war sie vorher nicht ausgenutzt worden.

ML-DSA selbst ist bereits in ähnlichen Fällen aufgefallen. Nur im Jahr 2026 wurden in drei unabhängigen Code-Repositories dieser Signaturlösung 4 Implementierungs-Schwachstellen offengelegt:

• In der Signatur-Implementierung von libgcrypt gibt es eine Out-of-Bounds-Write-Schwachstelle (CVE-2026-41990);

• Im RustCrypto ml-dsa crate existiert im Ablauf der hint-Berechnung eine Timing-Side-Channel-Schwachstelle, die zum Lecken von Signaturschlüsselinformationen führen kann (CVE-2026-22705);

• In demselben crate gibt es außerdem eine Verifikationsschwachstelle: Es akzeptiert fälschlicherweise Signaturen, die wiederholte hint-Indices enthalten (CVE-2026-24850);

• In dem wolfSSL-Code für post-quantum Krypto auf eingebetteten Geräten gibt es eine Fault-Injection-Schwachstelle (CVE-2026-3503).

Unter ihnen ist der Punkt, der am meisten ernst genommen werden sollte, eine Verifikationsschwachstelle: Nach dem FIPS-204-Standard hat eine gültige Signatur nur eine einzige legale Kodierungsform. Wenn eine Implementierung fälschlicherweise eine zweite Kodierung akzeptiert, dann könnte es davon abhängen, welchen Knoten du fragst, ob eine Signatur gültig ist. Auf einer Blockchain kann das direkt zu einer Kettenaufspaltung führen.

Zugleich gab es in derselben Zeit keine Angriffe, bei denen die zugrunde liegende Mathematik von ML-DSA selbst gebrochen wurde.

Mit anderen Worten: Die mathematische Grundlage ist derzeit weiterhin stabil; das eigentliche Risiko liegt eher in der Code-Implementierung.

Wir erwähnen dieses Beispiel immer wieder, weil es für alles, was wir veröffentlichen, einen sehr wichtigen und plausiblen Risikobewertungsmaßstab liefert. Auch die Ergebnisse der HAWK-Studie weisen in dieselbe Richtung: Die Prüfmechanismen, auf die wir in der Vergangenheit lange vertraut haben – inklusive manueller Audits, formaler Methoden und Code, der über viele Jahre offen überprüft wurde – haben diese Probleme nicht gefunden, während KI-unterstützte Analysen sie entdeckt haben.

Das bedeutet weiter, dass wir Folgendes brauchen:

• Bei der Wahl der Sicherheitsparameter ausreichend Sicherheitsreserve einplanen;

• Den Implementierungsumfang so klein wie möglich halten – und so gut wie möglich auditierbar;

• Cross-Implementation-Verifikation als zwingende Schwelle im Build-Prozess festlegen;

• Bei den neuesten, weniger ausgereiften Komponenten eine vorsichtigere, schrittweise Strategie für das Go-Live verfolgen.

Das ist auch der Grund, warum wir als Nächstes den folgenden Abschnitt diskutieren.

Diesen Knopf drücken wir vorerst nicht

Eigentlich gibt es einen noch besseren Shortcut als den, den wir derzeit verfolgen – aber wir werden ihn vorerst nicht wählen.

Jeder Ed25519-Schlüssel auf Sui wird aus einem hash-geschützten Seed abgeleitet. Selbst wenn Quantenrechner das elliptische Kurvenkryptosystem knacken, können sie nur den Signaturskalar wiederherstellen, aber nicht das ursprüngliche Seed, aus dem dieser Signaturskalar generiert wurde. Unsere Forschungsarbeit Post-Quantum Readiness in EdDSA Chains (Baldimtsi, Chalkias, Roy und Sedaghat, eprint 2025/1368) nutzt diese Asymmetrie und macht daraus einen quantenfesten Nachweis von Besitz: Nutzer können per Zero-Knowledge-Proof belegen, dass sie das ursprüngliche Seed besitzen, um gleichzeitig einen neuen post-quantum Schlüssel zu autorisieren – wobei die bestehende Adresse erhalten bleibt – und ohne dabei in irgendeiner Weise geheime Informationen offenzulegen.

Solch ein Schema hat einige bessere Eigenschaften als eine Migration über neue Ableitungspfade. Es eignet sich für Konten, deren Public Key bereits offengelegt ist; es lässt sich außerdem zurückverfolgend auf Schlüssel anwenden, die bereits vor vielen Jahren abgeleitet wurden. Sogar für inaktive Konten, die in Zukunft niemals wieder Transaktionen signieren werden, kann es funktionieren. Das ist eine Kategorie von Konten, die von anderen Migrationsschemata nicht abgedeckt wird. Und für Blockchains, die keine deterministische Seed-Ableitung unterstützen, kann diese Art von Konten sogar überhaupt nicht auf diesem Weg migriert werden. Das ist der strukturelle Vorteil von EdDSA-Blockchains gegenüber ECDSA-Blockchains – und genau deshalb beschäftigt sich diese Arbeit speziell mit EdDSA.

Wenn dieses Schema also so gut ist, warum aktivieren wir es jetzt nicht direkt? Weil dieser „Knopf“ im Kern ein Zero-Knowledge-Proof-System ist. Wenn wir ihn jetzt live schalten, würde die Kontensicherheit auf dieses Beweissystem angewiesen sein – und diese Technik ist selbst noch jünger als das Signaturschema, das sie schützen soll. Zusammen mit den zuvor erwähnten Implementierungsrisiken ist das genau der Grund für unsere Vorsicht.

Die Kosten, auf die wir warten müssen, sind in Wahrheit gering, weil dieser „Knopf“ nicht abläuft. Ein Seed wird nicht im Laufe der Zeit unverschlossen (bzw. nicht mehr geheim). Sobald das Zero-Knowledge-Proof-System genug Sicherheitsprüfungen und Vertrauen aufgebaut hat, können wir das Beweissystem weiterhin konstruieren und aktivieren. Gleichzeitig werden wir die Migration zunächst auf direktere Weise durchführen: über neue Ableitungspfade für native post-quantum Konten sowie mithilfe von Address Aliases für bestehende Konten.

Daher betrachten wir zkPQ-EdDSA für uns derzeit als einen Notfall-Schalter für zukünftige Aktivierung, falls dies nötig sein sollte – nicht als Startfunktion. Es gibt außerdem eine erwähnenswerte Design-Eigenschaft: Da der ML-DSA-Private-Key auf Sui ebenfalls ein 32-Byte-Seed ist, kann das „Seed-Besitz-Nachweis“-Mechanismus – falls künftig erforderlich – auch auf die post-quantum Konten selbst weiter angewendet werden.

Migrationsmechanismus

Bei zwei Sicherheits-Upgrades wird Sui jeweils neue standardisierte Ableitungspfade bereitstellen, und zwar über eine freiwillige Auswahl auf Kontenebene. Bestehende Konten müssen keine Gelder übertragen. Bereits bereitgestellte Adress-Aliases (Address Aliases) ermöglichen es einem Konto, den autorisierten Schlüssel auf einen post-quantum Schlüssel zu aktualisieren – dabei gilt: Adresse bleibt gleich, Vermögenswerte bleiben vor Ort. Für bestehende Nutzer ist es heute dieses Mechanismus, der die Migrationsarbeit tatsächlich übernimmt – nicht das zuvor erwähnte Zero-Knowledge-Proof-Schema, das derzeit noch verschoben wird.

Für einen quantenfesten Tresor verwendet das Abheben ein Zwei-Transaktionen-Modell; eine einfache Überweisung könnte sogar nur eine Transaktion benötigen. Für Entwickler und Institutionen ist die Bedeutung ganz klar: Quantenfeste Konten werden – ähnlich wie zkLogin und Passkeys – als neue optionale Funktion schrittweise eingeführt. Es gibt keine erzwungene Migration und bestehende Funktionen ändern sich nicht. Das Aktivieren ist lediglich ein normaler Protokoll-Feature-Upgrade, nicht eine Änderung am Konsensmechanismus oder am bestehenden Zustand.

Wie steht es aktuell in der Branche?

Wir sind nicht das einzige Team, das das macht, und wir möchten auch nicht das einzige sein. Near hat diesen Sommer bereits ML-DSA-65 als optionalen Schlüsseltyp eingeführt – mit derselben Lösung und Sicherheitsstufe wie Sui. Das ist ein wertvolles unabhängiges Signal. Die Ethereum-Konsens-Roadmap tendiert stärker zu hash-basierten Ansätzen. Bitcoin hat derzeit mehrere aktive Vorschläge, aber noch keine endgültige Entscheidung getroffen.

Wir finden, dass Sui nicht deshalb wirklich vorne liegt, weil wir einen bestimmten Algorithmus gewählt haben, sondern weil wir eine Architekturentscheidung getroffen haben:

• Zwei Lösungen entsprechen zwei Bedrohungsmodellen;

• Ein Tresor kann sich an externe Standards anpassen, ohne dass das Protokoll upgraden muss;

• Nutzer können die ursprüngliche Adresse behalten.

Aktueller Stand und Zeitplan

Die Kernimplementierung ist bereits abgeschlossen und wurde getestet. Geplant ist:

• Quantenfester Tresor: Dieses Jahr im Mainnet;

• Native ML-DSA-65-Konten: bis zum Jahresende im Testnet;

• Native Kontobestätigung: spätestes Ziel ist, bis ins erste Quartal 2027 ins Mainnet zu gehen.

Wallet-, SDK- und CLI-Unterstützung werden synchron veröffentlicht.

Unabhängige externe Audits laufen derzeit. Wir können nicht garantieren, dass alle Audits vollständig wie geplant abgeschlossen werden. Daher verschieben wir lieber den Termin, als einen Authenticator live zu schalten, der nicht ausreichend geprüft wurde. Deshalb stellt dieser Artikel die aktuelle Richtung vor; der endgültige Zeitpunkt kann sich je nach Audit-Ergebnissen und Rückmeldungen aus dem Testnet noch ändern.

Alles, was für die zugehörigen Audits erforderlich ist, ist bereits öffentlich, einschließlich FIPS 204, FIPS 205, formal verifizierter mldsa-native-C-Implementierungen, der nativen Rust-Wrapper von Mysten (mysten-mldsa-native-rs) sowie unserer derzeit bewusst noch zurückgehaltenen Open-Source-Implementierung von Post-Quantum Readiness in EdDSA Chains.

Anstatt auf Lob zu hoffen, möchten wir, dass diese Arbeit kritisch begutachtet wird. Wir haben bewusst den Implementierungsumfang so klein wie möglich gehalten, bewusst Cross-Verification als zwingende Schwelle im Build-Prozess gesetzt und bewusst die Verwendung von Migrations-Abkürzungen verschoben. Wenn du an post-quantum Signaturen, Hardware-Wallets oder Proof-Systemen arbeitest und der Ansicht bist, dass eine der Entscheidungen problematisch ist, dann würden wir uns sehr über dein Feedback freuen.

Ein Osterei

Der Ableitungspfad ist die Regel, nach der eine Wallet einen Seed-Satz (Mnemonic) in mehrere Schlüssel umwandelt: Er besteht aus einer kurzen Folge von Zahlen, die der Reihe nach schrittweise angewendet werden. Dadurch kann derselbe Seed-Satz auf jedem beliebigen Gerät exakt die gleichen Schlüssel erzeugen. Alle mnemonic-basierten Schlüssel auf Sui werden über diesen Pfad abgeleitet; die erste Zahl darin – die Zwecknummer – dient zur Kennzeichnung des Signaturschemas.

Aktuell verwendet Sui für Ed25519-Schlüssel den folgenden Ableitungspfad:

m/44'/784'/0'/0'/0'

Dabei steht 784' für Sui, 44' für die Zwecknummer; das ECDSA-Signaturschema verwendet jeweils 54' und 74'. Post-Quantum-Schlüssel werden verwendet mit:

m/94'/784'/0'/0'/0'

Die 94 hier ist nicht nur die nächste Zahl in einer Sequenz – sie steht für ein Jahr. Zufällig ist Peter Shor genau 1994 auf dem Papier mit dem Algorithmus hervorgetreten, der all das nötig machte. Um dieses Zusammentreffen zu ehren, enthält jeder Ableitungspfad eines Sui-quantensicheren Schlüssels das Jahr, in dem dieser Countdown begonnen hat.