19.397 physische Qubits. 1.457 logische Qubits. 39 Millionen Toffoli-Gatter auf logischer Ebene. Und am Ende der Rechnung: 25,7 Tage pro Versuch, das elliptische Kurven-Diskrete-Logarithmus-Problem (ECDLP) auf der Kurve secp256k1 zu lösen. Das ist keine Science-Fiction-Folie. Das ist die End-to-End-Schätzung, die IonQ am 8. September in einem voll kompilierten Blueprint vorgelegt hat — und die Unternehmen, Wallet-Betreiber und Code-Signing-Teams konkret einpreisen sollten.
Rechnen wir nach: Bei einer bewiesenen unteren Erfolgswahrscheinlichkeit von rund 40,7 Prozent pro Versuch liegt die erwartete Zahl der Läufe grob bei 1 ÷ 0,407 ≈ 2,5. Multipliziert mit 25,7 Tagen ergibt das eine Kalenderordnung von etwa 64 Tagen reiner Rechenzeit — ohne Warteschlangen, ohne Wartungsfenster, ohne politische Verzögerung. Unter gängigen Heuristiken steigt die Erfolgswahrscheinlichkeit auf bis zu 63,3 Prozent; dann sinkt die erwartete Versuchszahl Richtung 1,6 und die Kalenderordnung Richtung 41 Tage. Der Haken: Das ist Capability-Rechnung, kein Live-Angriff. Kein Wallet wurde angefasst. Kein Schlüsselnetzwerk berührt. Eine fault-tolerante Maschine dieser Klasse existiert heute nicht.
Unter dem Strich verschiebt der Blueprint die Diskussion von „irgendwann vielleicht“ zu „Roadmap-Fenster um 2028“. Was heißt das für Signaturen, Zertifikatshierarchien und die Kosten einer Migration auf Post-Quanten-Kryptografie (PQC)? Genau das sortieren wir hier — These, Beleg, Beispiel, Einordnung.
19.397 Qubits und 25,7 Tage: Was IonQ konkret vorrechnet
IonQ hat laut eigener News-Mitteilung den ersten vollständig kompilierten End-to-End-Blueprint veröffentlicht, der das Brechen 256-Bit-Elliptischer-Kurven-Signaturen auf einer fault-toleranten Trapped-Ion-Architektur durchrechnet. Der begleitende Paper-Titel lautet: Computing 256-bit elliptic curve discrete logarithms in 26 days on a fault-tolerant trapped-ion quantum computer with 20,000 qubits. Die Rundung „26 Tage“ im Titel und die Detailzahl 25,7 Tage im Stack gehören zusammen — die Detailrechnung ist die belastbare Bezugsgröße.
Die Kernzahlen aus News und IonQ-Blog sind eindeutig: 19.397 physische Qubits, 1.457 logische Qubits, 39 Millionen Toffoli- bzw. CCZ-Operationen auf logischer Ebene, 25,7 Tage pro Versuch gegen secp256k1. Die Success-Probability-Lower-Bound liegt bei etwa 40,7 Prozent (bewiesen); unter üblichen Heuristiken bis 63,3 Prozent. Als Error-Correction-Zykluszeit referenziert IonQ 29,5 Millisekunden — gemessen, nicht frei erfunden.
Zum Vergleich: Frühere Abschätzungen zum Shor-Angriff auf ECC arbeiteten oft mit abstrakten Gate-Counts und idealisierten Overhead-Faktoren. Hier wird der Stack durchkompiliert — Speicherblöcke, Factories, Routing, Verlustmodell. Das ist der qualitative Sprung: aus einer Physik-Skizze wird eine Maschinenrechnung.
| Größe | Wert laut IonQ | Einordnung |
|---|---|---|
| Physische Qubits | 19.397 | Hardware-Budget der Schätzung (~20k-Klasse) |
| Logische Qubits | 1.457 | Fehlerkorrigierte Arbeitsqubits für den Algorithmus |
| Toffoli/CCZ (logisch) | 39 Millionen | Kernmaß für die algorithmische Arbeit |
| Laufzeit pro Versuch | 25,7 Tage | End-to-End, inkl. Stack-Overheads |
| Erfolg (Lower Bound) | ~40,7 % | Bewiesen; Heuristik bis ~63,3 % |
| EC-Zykluszeit | 29,5 ms | Referenzierte Messgröße |
| Architektur | Walking Cat + qLDPC | 69 Memory-Blöcke, 4 Factories; natives CCZ ~31× schneller |
| Routing-Overhead | ~5 % der Laufzeit | Deutlich unter naiven Annahmen |
Die Tabelle ist Absicht. Wer nur „Quantencomputer knacken Bitcoin“ liest, verpasst die Rendite der Detailarbeit: Routing frisst laut Blueprint nur rund fünf Prozent der Laufzeit. Das Ionenverlust- und Leakage-Modell reduziert die Qubits pro Block um ein Drittel gegenüber einer naiven Auslegung. Optimiert stehen 69 Memory-Blöcke und vier Factories — mit nativem CCZ, das IonQ als etwa 31-mal schneller als eine naive Zerlegung beschreibt.
ECDLP, physische vs. logische Qubits und Toffoli — kurz und belastbar
ECDLP steht für Elliptic Curve Discrete Logarithm Problem: Aus einem öffentlichen Punkt auf der Kurve soll der geheime Skalar rekonstruiert werden, der die Signatur authentifiziert. Bei secp256k1 — der Kurve hinter Bitcoin-Authentifizierung und vielen weiteren ECC-Einsätzen — bedeutet ein gelöstes ECDLP: Private Keys werden ableitbar, Signaturen fälschbar. Vertraulichkeit aufgezeichneter TLS-Sessions ist hier nicht das Primärrisiko. Der Angriff trifft Authentizität und Integrität.
Physische Qubits sind die Hardware-Einheiten in der Ionenfalle. Logische Qubits sind fehlerkorrigierte Verbünde aus vielen physischen Qubits; erst sie tragen den Algorithmus über Wochen. Toffoli (CCZ/CCNOT) ist das teure Mehrqubit-Gatter, an dem sich fault-tolerante Kosten oft messen. Walking Cat (Architektur-Update vom April) plus qLDPC-Codes (quantum Low-Density Parity-Check) sind der Stack, der Speicher, Factories und Korrektur so zusammensetzt, dass die 20.000er-Klasse überhaupt in die 25,7-Tage-Rechnung passt.
These: Ohne diesen Stack bliebe die physische Qubit-Zahl deutlich höher oder die Laufzeit deutlich länger. Beleg: IonQ selbst stellt natives CCZ und die Block/Factory-Aufteilung als Hebel heraus. Beispiel: Ein Drittel weniger Qubits pro Block durch realistisches Loss/Leakage-Modell verändert die CapEx-Kurve einer künftigen Maschine spürbar. Einordnung: Für Security-Teams zählt weniger die Marke „IonQ“ als die Größenordnung — zehntausende physische Qubits, unter zwei Wochen bis zwei Monaten effektiver Angriffszeit je nach Success-Annahme.
Erwartungswert: 25,7 Tage mal 40,7 Prozent Success
Rechnen wir nach, ohne die Schätzung zur Prophezeiung zu machen. Ein Versuch kostet 25,7 Tage Maschinenzeit. Die bewiesene untere Erfolgsschranke liegt bei ~40,7 Prozent. Erwartete Versuche: 1 / 0,407 ≈ 2,46. Erwartete reine Rechenzeit: 2,46 × 25,7 ≈ 63 Tage. Mit der Heuristik-Obergrenze 63,3 Prozent sinkt der Erwartungswert auf etwa 1,58 Versuche und rund 41 Tage.
Zum Vergleich: Klassische Brute-Force gegen 256-Bit-ECC ist praktisch ausgeschlossen; die Sicherheit ruht auf ECDLP-Härte, nicht auf Keyspace-Exhaustion im üblichen Sinn. Der Blueprint sagt nicht: „Morgen ist alles weg.“ Er sagt: Wenn eine fault-tolerante Trapped-Ion-Maschine dieser Spezifikation existiert und mit diesem Stack betrieben wird, liegt ein ECDLP-Versuch in der Größenordnung eines Monats — nicht eines Jahrzehnts.
Der Haken für Risikomanagerinnen und Risikomanager: Erwartungswert ist keine Garantie. Ein einzelner Versuch kann scheitern; zwei können reichen; drei können nötig sein. Parallelisierung mehrerer Maschinen würde die Kalenderzeit drücken — und gleichzeitig CapEx und Betriebskosten multiplizieren. Lohnt sich das für einen Angreifer? Das hängt vom Wert der Ziel-Keys ab. Für einen einzelnen Retail-Wallet eher nein. Für Wurzeln der Vertrauenskette, Code-Signing-Keys oder hochvolumige Custody-Setups sieht die Rendite-Rechnung anders aus.
Wichtig bleibt die Klarstellung aus dem Briefing und den IonQ-Materialien: Es gibt keinen Live-Angriff. Kein fähiges FT-System dieser Klasse steht heute bereit. Responsible Disclosure an US-Regierung und Industrie lag vor der Veröffentlichung. Das ist Wissenschaftskommunikation mit Security-Ethik — kein Exploit-Drop.
secp256k1 als Canary: Was der Blueprint für Wallets bedeutet
secp256k1 ist bewusst gewählt: Canary und Benchmark zugleich. Bitcoin-Authentifizierung hängt an ECC-Signaturen; zugleich generalisiert die Methodik auf RSA-2048 und auf Kurven, die in TLS und VPN stecken. Wer nur „Bitcoin-Apokalypse“ hört, denkt zu eng. Wer nur „ein Paper“ hört, denkt zu klein. Die richtige Lesart liegt dazwischen: Capability-Milestone plus Migrationsdruck.
Konkret für Wallets: UTXO, die an alten Adressen mit exponiertem Public Key hängen, sind das klassische Szenario in der Debatte um Quantenrisiko — ausführlicher bereits in unserem Stück zur Diskussion um Abrufrisiken bei Millionen BTC durch Quantencomputer. Der IonQ-Blueprint ändert daran die Zeitskala der Plausibilität, nicht die Grundmechanik. Unter dem Strich: Wer Keys rotiert, Multisig pflegt und Migrationspfade kennt, steht besser da als wer „noch Zeit“ als Strategie verkauft.
Für Krypto-Holderinnen und Holder bleibt die Einordnung nüchtern, wie wir sie auch bei Blockchain und Post-Quanten-Kryptografie für Krypto-Holder skizziert haben: Das Risiko ist Signaturfähigkeit, nicht magisches Leeren aller Ketten über Nacht. Custody-Anbieter, Börsen und Self-Custody-Setups brauchen Fahrpläne — nicht Panikposts. Wer Adressen mit dauerhaft sichtbarem Public Key betreibt, priorisiert Rotation und Policy strenger als wer Keys eng hält und selten reused. Das klingt banal. Es ist trotzdem der Hebel, den viele Debatten überspringen.
Code-Signing, Zertifikate und Roots of Trust — dort sitzt der Schmerz
Hier wird es für Enterprise ungemütlich. Authentifizierung und Integrität betreffen weit mehr als Coin-Transfers. Code-Signing-Keys entscheiden, ob eine Firmware-Aktualisierung vertrauenswürdig ist. Geräteidentitäten und Zertifikatshierarchien steuern, wer sich als wer ausgeben darf. Roots of Trust in Hardware-Sicherheitsmodulen und PKI-Ketten sind genau die Assets, deren Kompromittierung hohe Rendite für Angreifende verspricht — und hohen Schaden für Betroffene.
These: Der Blueprint erhöht den Druck auf lange Schlüssel-Lebenszyklen. Beleg: 25,7 Tage pro Versuch bei ~20k physischen Qubits ist eine andere Bedrohungsklasse als abstrakte „Quanten in 30 Jahren“-Folien. Beispiel: Ein Code-Signing-Zertifikat mit fünf Jahren Laufzeit und schwacher Rotation ist in einer Welt mit FT-Maschinen der 2028er-Roadmap ein anderes Risikoobjekt als 2018. Einordnung: Harvest-now-decrypt-later für aufgezeichneten Traffic ist hier nicht der Leitgedanke. Es geht um gefälschte Signaturen, wenn der Private Key rekonstruierbar wird.
Zum Vergleich: Vertraulichkeit (Verschlüsselung von Datenströmen) und Authentizität (Signaturen) folgen unterschiedlichen Migrationslogiken. Wer nur TLS 1.3 cipher suites tauscht, aber Signing- und Identity-Stacks unangetastet lässt, hat den Haken übersehen. BSIG §8a verlangt von Betreibern kritischer Infrastruktur angemessene organisatorische und technische Vorkehrungen — dazu gehört perspektivisch auch die Bewertung kryptografischer Agilität, nicht nur das Abhaken heutiger Baselines.
Praktisch heißt das: Inventar der Signaturverfahren. Lebensdauer der Keys. Abhängigkeiten zu Zulieferern. Testpfade für PQC-Signaturen parallel zum Bestand. Wer das erst startet, wenn die erste FT-Demo öffentlich Schlüssel materialisiert, zahlt Aufpreis in Panik-Projekten — und Panik-Projekte haben bekanntermaßen schlechte Rendite.
PQC-Kosten: ML-DSA und SLH-DSA gegen das Risiko rechnen
Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2Promptwallet post-quantum cryptographyDie Mitigation-Seite ist klar benannt: NIST ML-DSA (FIPS 204) und SLH-DSA (FIPS 205). Das sind standardisierte digitale Signaturverfahren der Post-Quanten-Ära. ML-DSA basiert auf Gitterproblemen (Dilithium-Linie); SLH-DSA auf hashbasierten Signaturen (SPHINCS+-Linie). Beide adressieren genau die Authentizitätslücke, die ein Shor-fähiges ECDLP auf klassischen Kurven aufreißen würde.
Rechnen wir grob nach — ohne Scheingenauigkeit. Eine typische Enterprise-Migration umfasst: Krypto-Inventar, Pilot auf nichtkritischen Signaturpfaden, HSM-/KMS-Fähigkeit, Zertifikatsprofil-Updates, Client- und Geräte-Kompatibilität, Rollback-Pläne, Schulung der Beschäftigten. Kostenblöcke entstehen vor allem in Integration und Lifecycle, nicht im Algorithmusnamen auf dem Papier. Zum Vergleich: Ein gescheiterter Root-Key oder ein gefälschtes Massen-Update kann Betriebs- und Haftungskosten erzeugen, die ein geordnetes PQC-Programm um Größenordnungen übersteigen.
| Hebel | Klassische ECC (Status quo) | PQC-Migration (ML-DSA / SLH-DSA) |
|---|---|---|
| Primärrisiko laut Blueprint | ECDLP auf secp256k1 & Verwandte | Signaturverfahren ohne Shor-ECDLP-Pfad |
| Zeithorizont Druck | Roadmap-Fenster ~2028 (IonQ) | Jetzt starten, stufenweise ausrollen |
| Typische Kostenart | Niedrig im Betrieb, hoch im Schadenfall | Projekt- und Lifecycle-Kosten, planbar |
| Normative Anker | Bestehende PKI / ECC-Profile | NIST FIPS 204 / 205; Agilität in Policies |
| Lohnt sich wann? | Solange keine FT-Capability | Wenn Key-Lebensdauer ins Fenster reicht |
Unter dem Strich: PQC lohnt sich dort zuerst, wo Schlüssel lange leben, weit verstreut sind oder Wurzeln der Vertrauenskette bilden. Kurzlebige Session-Artefakte sind nicht der Engpass. Lange Code-Signing- und Geräteidentitäts-Ketten sind es. Wer interne Lesende und externe Auditoren überzeugen muss, verweist auf die NIST-FIPS-204-Seite zu ML-DSA und die parallele SLH-DSA-Linie — und auf ein eigenes Inventar, nicht auf Twitter-Timelines.
Mehr Kontext zur Einordnung von Quantenrisiko und Migration finden Lesende auch in unserem Überblick zur Post-Quanten-Kryptografie — der Blueprint von IonQ ist der aktuelle Zahlenanker, nicht der Ersatz für Architekturarbeit.
Roadmap-Fenster: 10.000 physische Qubits zuerst, dann die 20.000er-Klasse
IonQ ordnet den Blueprint an der eigenen Roadmap aus: Ausrichtung grob auf 2028. CEO Niccolo de Masi spricht von einem vollständig fault-toleranten System mit 10.000 physischen Qubits in 2027 und weiteren Fortschritten 2028. Das ist Unternehmens-Roadmap, kein Naturgesetz. Roadmaps rutschen. Budgets kippen. Physik bleibt hart.
Trotzdem gilt für die Planung: Wenn ein Hersteller öffentlich End-to-End-Zahlen für ~20k physische Qubits und ECDLP in unter einem Monat vorlegt, verschiebt sich das „frühestmögliche glaubwürdige Fenster“ für risk-averse Teams nach vorn. Security-Boards brauchen keine Gewissheit über das genaue Quartal. Sie brauchen eine Entscheidung, ob Key-Rotation und PQC-Piloten 24 Monate Vorlauf bekommen — oder 24 Wochen Chaos.
Der Haken an reiner Roadmap-Gläubigkeit: Capability entsteht nicht linear. Fehlerkorrektur, Ionenverlust, Factory-Durchsatz und Software-Stack müssen gleichzeitig skalieren. Der Blueprint zeigt, dass unter den angenommenen Parametern die Mathematik aufgeht. Er beweist nicht, dass die Fabrik 2028 fertig ist. Einordnung mit kühlem Kopf: Behandeln Sie 2027/2028 als Planungshorizont für Migrationstests, nicht als Fixtermin für den Untergang von ECC.
Für FinTech-Teams, die Quantencomputing bisher als Fernfeld abgehakt haben, ändert sich die Folie: Aus „Beobachten“ wird „Budgetieren“. Wer das mit der breiteren Debatte zu Quantencomputern im FinTech-Umfeld verknüpfen will, findet dort den Cluster — der IonQ-Text liefert jetzt die härtesten öffentlich durchgerechneten ECDLP-Zahlen der 20.000er-Klasse.
Was Unternehmen jetzt tun — und was sie lassen
Konkret, ohne Theater:
- Krypto-Inventar: Welche Systeme nutzen secp256k1, verwandte ECC-Kurven oder RSA-2048 für Signaturen und Identitäten?
- Key-Lebensdauer: Welche Secrets leben länger als das Roadmap-Fenster um 2028?
- Agilität testen: ML-DSA und SLH-DSA in Labor und Staging, nicht erst in der Krise.
- Zulieferverträge: Code-Signing und Geräte-PKI der Vendoren abfragen — wer migriert wann?
- Kommunikation: Intern Capability-Milestone erklären, extern Alarmismus vermeiden.
Lassen Sie: „Bitcoin ist tot“-Headline-Denken. Lassen Sie: Warten auf den perfekten globalen Cut-over. Lassen Sie: Verwechseln von Vertraulichkeits-Harvesting mit Signaturbruch. Der Blueprint trifft Authentizität und Integrität. Das ist scharf genug — und präzise genug, um Budgets zu rechtfertigen.
Für Aufsicht und interne Revision hilft die Sprache der Angemessenheit. BSIG §8a und branchenspezifische Vorgaben verlangen keine Prophetie. Sie verlangen nachvollziehbare Risikoanalyse. Ein Paper mit 19.397 physischen Qubits, 39 Millionen Toffoli und 25,7 Tagen Laufzeit ist ein Belegstück für genau diese Analyse — neben den NIST-Standards FIPS 204 und 205 als Mitigationsanker.
Kostenvergleich grob: Migration vs. Integritätsbruch
Noch eine Rechnung, diesmal ohne Pseudo-Cent-Genauigkeit. Angenommen, ein mittelgroßes FinTech-Unternehmen inventarisiert 40 signaturrelevante Systeme, davon acht mit Keys, deren Lebensdauer über das Roadmap-Fenster hinausreicht. Ein geordnetes PQC-Pilotprogramm für zwei Pfade (ein Online-Service, ein Code-Signing-Strang) kostet intern oft im niedrigen bis mittleren sechsstelligen Bereich — abhängig von HSM-Landschaft, Vendor-Lock und Testaufwand. Parallelbetrieb für zwölf bis achtzehn Monate verdoppelt eher den Integrationsanteil als den Algorithmusanteil.
Zum Vergleich: Ein kompromittierter Code-Signing-Key mit nachgelagerter Notfall-Rotation, Kundenkommunikation und forensischer Aufarbeitung kann denselben Betrag in Wochen verbrennen — zuzüglich Vertrauensverlust, den keine Excel-Zeile sauber erfasst. Der Blueprint von IonQ ändert nicht die Buchungslogik. Er ändert die Eintrittswahrscheinlichkeit im Planungszeitraum. Genau dort sitzt die Rendite von Agilität: Sie kaufen Optionen auf einen geordneten Wechsel, nicht die Garantie, dass 2028 die Maschine steht.
Konkret für Controllerinnen und Controller: Trennen Sie „Forschung beobachten“ (Opex-klein) von „Krypto-Agilität aufbauen“ (Projektbudget). Der zweite Posten lässt sich gegen Residualrisiko rechnen. Der erste allein erzeugt Folien. Folien schützen keine Roots of Trust.
Ein zweites Rechenbeispiel zur Success-Logik, weil Erwartungswerte gerne missverstanden werden: Bei 40,7 Prozent Erfolg pro Lauf scheitern statistisch mehr als die Hälfte der Einzelversuche. Das ist kein Widerspruch zur Bedrohung. Es bedeutet nur, dass Angreifende mit Budget für Wiederholung planen — oder mit Heuristiken, die die Chance Richtung 63,3 Prozent schieben. Unter dem Strich bleibt die Größenordnung „Wochen bis wenige Monate“, nicht „Jahrzehnte“.
Der Haken für öffentliche Debatten: Medien lieben das Wort „knacken“. Security-Teams brauchen „kompilierter Stack, fault-tolerant, Signaturen“. Wer intern nur die Headline weiterleitet, erzeugt entweder Lähmung oder Gleichgültigkeit. Beides lohnt sich nicht. Liefern Sie die Tabelle, die Success-Rechnung und den Mitigationsanker FIPS 204/205 — dann können Beschäftigte priorisieren.
Unter dem Strich: Milestone, nicht Grabstein
19.397 physische Qubits. 1.457 logische. 39 Millionen Toffoli. 25,7 Tage. Success-Lower-Bound 40,7 Prozent, Heuristik bis 63,3 Prozent. Walking Cat plus qLDPC, 69 Blöcke, 4 Factories, Routing ~5 Prozent, natives CCZ ~31×. Roadmap-Fenster ~2028. Kein Live-System angegriffen. Risiko in Signaturen, Code-Signing, Zertifikaten, Geräteidentität. Mitigation: ML-DSA und SLH-DSA.
Rechnen wir das für die Entscheidungsvorlage zusammen: Die erwartete reine Angriffszeit gegen secp256k1 liegt unter den genannten Annahmen in der Größenordnung von gut einem bis zwei Monaten Maschinenzeit — sofern die Maschine existiert. Heute existiert sie nicht. Morgen wird sie nicht aus dem Nichts erscheinen. Zwischen „nicht“ und „erscheinen“ liegt genau die Phase, in der Migration Rendite bringt: planbare Projektkosten gegen unplanbaren Integritätsbruch.
Ihr Bank- oder Custody-Berater wird das ungern als „schon erledigt“ abtun wollen — zu Recht, wenn noch kein Inventar liegt. Gleichzeitig darf niemand so tun, als sei die Chain abschaltreif. Der Blueprint ist ein Capability-Milestone mit Migrationsdruck. Ob sich PQC für Ihr Setup lohnt, entscheiden Key-Lebensdauer, Angriffsfläche und Aufsichtserwartung — nicht der lauteste Feed.
Offen bleibt, wie schnell fault-tolerante Trapped-Ion-Systeme die 10.000er- und 20.000er-Klasse industriell erreichen; offen bleibt, wie zügig Software-Ökosysteme PQC-Signaturen in der Breite verkraften; offen bleibt, welche Kurven und Verfahren zuerst weichen. Geschlossen ist die Ausrede, man habe keine Zahlen gehabt. Die Zahlen liegen auf dem Tisch. Jetzt wird gerechnet — und priorisiert. Ob Ihr Gremium den Blueprint als Forschungsnotiz oder als Budgetimpuls liest, entscheidet am Ende über die Rendite der nächsten zwei Budgetjahre.

