Post‑Quantum Krypto im Praxistest: Lattice vs. Code im Vergleich

Zuletzt aktualisiert: 12. Oktober 2025

Kurzfassung

Verschiedene Post‑Quantum‑Kryptoverfahren werden aktuell im Live‑Testbetrieb verglichen. Dieser Beitrag liefert einen klaren Post Quantum Krypto Vergleich, konzentriert auf PQC Fehlerquoten, Latenz und Schlüsselgrößen. Wir erklären, wie Lattice‑Verfahren (Kyber) und code‑basierte Verfahren (Classic McEliece) in der Praxis performen, welche Messgrößen wirklich zählen und welche Kriterien bei Migration und Auswahl helfen.


Einleitung

In den Labors der Kryptografie laufen derzeit praktische Tests, die eine einfache Frage beantworten sollen: Welche Post‑Quantum‑Verfahren funktionieren wirklich unter Alltagsbedingungen? Der Begriff Post Quantum Krypto Vergleich taucht in Berichten und Foren immer häufiger auf — und das aus gutem Grund. Theoretische Sicherheit ist eine Sache, praktische Fehlerquoten, Schlüsselgrößen und Rechenaufwand eine andere. Dieser Artikel nimmt zwei sehr unterschiedliche Kandidaten unter die Lupe: die populären Lattice‑Ansätze (Kyber) und klassische, code‑basierte Verfahren (Classic McEliece). Ziel: konkrete Messergebnisse, klare Empfehlungen und pragmatische Migrationstipps für Entwickler und Entscheider.


Lattice vs. Code‑basierte PQC – kurz erklärt

Auf den ersten Blick ähneln sich alle Post‑Quantum‑Algorithmen: Sie sollen auch gegen Quantenrechner sicher bleiben. Der Unterschied zeigt sich in Bauweise und Betrieb. Lattice‑Verfahren wie Kyber nutzen mathematische Gitterstrukturen; sie sind schlank bei Schlüssel‑ und Ciphertext‑Größen und relativ einfach in bestehende Protokolle einzubauen. Code‑basierte Verfahren wie Classic McEliece setzen auf Fehlerkorrektur‑Codes — sie bieten seit Jahrzehnten nachvollziehbare Sicherheit, verlangen aber häufig riesige öffentliche Schlüssel.

Warum das wichtig ist: In einer Web‑Handshake‑Sequenz zählt jedes Byte, in eingebetteten Sensoren jedes Kilobyte. Lattice‑Schemes sind deshalb attraktiv für Bandbreiten‑ und Speicher‑kritische Szenarios. Code‑basierte Ansätze glänzen dagegen dort, wo hohe Konservativität und lange Zeiträume gefragt sind — etwa bei staatlichen Archiven oder bestimmten Infrastrukturen, die Keys selten austauschen, aber sehr lange archivieren.

“Lattice: klein, schnell, oft praktikabel. Code‑basiert: konservativ, aber groß—ein Tausch von Bytes gegen Vertrauen.”

Ein weiteres Unterscheidungsmerkmal ist die Fehlerwahrscheinlichkeit beim Entschlüsseln: Manche Konstrukte definieren eine theoretisch sehr kleine Decapsulation‑Failure‑Rate (DFR). Bei Kyber nennt die Spezifikation DFR‑Werte (z. B. sehr kleine Exponenten) — das ist aber eine theoretische Größe, die im Feld anders aussehen kann, wenn RNGs, Compiler‑Optimierungen oder Implementationsfehler ins Spiel kommen (Datenstand älter als 24 Monate bei Spezifikationen: PQCrystals 2021; siehe Quellen).

Technik‑Fans sollten zwei Dinge beachten: 1) Architekturabhängigkeit — AVX2‑optimierte Builds auf Servern unterscheiden sich stark von ARM‑Implementierungen in Sensoren; 2) Implementierungsdetails — Patches und constant‑time‑Prüfungen sind Pflicht, sonst können Timing‑Effekte reale Probleme erzeugen.

Nach diesem Überblick gehen wir nun in die Messdaten: Fehlerquoten, Latenz und Schlüsselgrößen — und was die Zahlen im Alltag wirklich bedeuten.

Messergebnisse: Fehlerquoten, Latenz, Schlüsselgröße

In Laboren und Testbeds werden drei Werte besonders beobachtet: Decapsulation‑Failure‑Rate (DFR), Latenz/CPU‑Zyklen und Speicherbedarf (Public/Secret Key plus Ciphertext). Hier eine knappe, überprüfbare Zusammenstellung basierend auf Spezifikationen und Benchmarks (liboqs) sowie aktuellen Sicherheitsmeldungen.

Schlüssel‑ und Ciphertext‑Größen (typische Werte): Kyber parametriert kompakt — Kyber512: Public Key ≈ 800 B, Ciphertext ≈ 768 B; Kyber768: PK ≈ 1 184 B, CT ≈ 1 088 B; Kyber1024: PK ≈ 1 568 B, CT ≈ 1 568 B (PQCrystals, Spezifikation 2021 — Datenstand älter als 24 Monate). Classic McEliece hingegen hat sehr große Public Keys: Beispiel mceliece348864: PK ≈ 261 120 B, Ciphertext sehr klein (≈ 96 B); andere Sicherheitsstufen erreichen mehrere hundert KB bis mehrere MB (Classic McEliece Spec 2022 — Datenstand älter als 24 Monate).

Failure‑Raten: Theoretisch legt die Kyber‑Spezifikation extrem kleine Decapsulation‑Failure‑Wahrscheinlichkeiten fest (z. B. in der Größenordnung 2^-139 bis 2^-174 je nach Parameter). Diese Werte sind design‑bezogen; messbar sind sie in der Praxis nur schwer — für präzise Schätzungen wären astronomisch viele Versuche nötig. Praktische Messungen konzentrieren sich daher auf Implementationstests: KATs, Stresstests und die Überprüfung auf Implementations‑Bugs. Ein realer Vorfall (CVE‑2024‑36405) zeigte, dass Timing‑Effekte in Referenzimplementationen ausgenutzt werden können — patches sind deshalb unabdingbar.

Latenz/Performance: Benchmarks aus liboqs und PQCrystals liefern Cycle‑Counts für verschiedene Architekturen. Auf modernen Servern mit AVX2 sind Kyber‑Operationen sehr schnell und throughput‑freundlich; auf ARM‑Cortex‑M‑Klassen verlangsamt sich der Algorithmus deutlich. Classic McEliece kostet oft mehr Speicher und führt zu höheren Speicher‑Footprints beim Key‑Management, während die reine Rechenlast beim Ver- und Entschlüsseln je nach Implementation variieren kann.

Merkmal Kyber (Lattice) Classic McEliece (Code)
Public Key ~800–1 568 B ~261 120 B bis mehrere MB
Ciphertext ~768–1 568 B ~96–208 B
Theor. DFR sehr klein (z. B. 2^-139 … 2^-174) designbedingt sehr gering; anders zu messen

Wichtig: Viele Benchmarks sind reproduzierbar, wenn man liboqs (aktuelle, gepatchte Version) nutzt und Hardware/Compiler dokumentiert. Direkte Messung extrem kleiner Fehlerwahrscheinlichkeiten ist in der Praxis oft nicht möglich; stattdessen stehen KATs, Stresstests und SCA/Timing‑Analysen auf dem Prüfstand.

Anwendungsfälle: IoT, Netzwerke, Sensorik

Die praktische Frage lautet selten “Was ist theoretisch sicher?”, sondern immer: “Was funktioniert in meinem Kontext?” In IoT‑Netzen mit beschränkter Bandbreite und geringem Speicher sind Kyber‑ähnliche Lattice‑Verfahren oft die beste Wahl: kleine Schlüssel, moderate Rechenkosten und einfache Integration in TLS/DTLS‑Handshakes. Ein typisches Beispiel ist ein Mesh‑Sensor, der nur wenige Kilobyte Flash hat — hier ist ein 1‑KB Public Key deutlich handhabbarer als mehrere hundert KB.

Bei Netzwerkinfrastrukturen wie VPN‑Gateways oder Servern kommt es auf Durchsatz an. Auf Hosts mit AVX2/AVX512‑Unterstützung liefert Kyber sehr niedrige Latenzen und hohe Throughput‑Werte; Benchmarks auf modernen Servern zeigen, dass Kyber‑KEMs in vielen Fällen die Latenz‑Budget‑Anforderungen erfüllen. Classic McEliece kann hier immer noch eine Rolle spielen, etwa wenn Schlüssel selten verteilt und lange aufbewahrt werden — etwa für Backup‑Verfahren oder Archivierung, wo der Overhead beim Key‑Management einmalig ist, der langfristige Schutz aber geschätzt wird.

In der Sensorik und bei sehr ressourcenbeschränkten Geräten ist die Rechnung oft eng: CPU‑Zyklen gegen Energieverbrauch, Flash gegen Flexibilität. Hier empfiehlt es sich, Hybride Ansätze zu prüfen: einen klassischen, bewährten Algorithmus mit einem Post‑Quantum‑Algorithmus zu kombinieren, um eine graduelle Migration zu ermöglichen. Dieser Weg reduziert Risiken, erhöht aber die Bandbreitenkosten.

Praxisregel: Messt auf der Zielhardware. Viele Performance‑Aussagen verallgemeinern von Server‑Benchmarks; für IoT‑Boards oder ältere ARM‑Cores weichen die Werte oft deutlich ab. Nutzt liboqs‑Benchmarks, führt KATs und Stresstests durch und dokumentiert die Build‑Parameter — nur so sind Aussagen über Fehlerquoten und Latenz belastbar.

Abschließend ein Blick auf Key‑Management: Große Public Keys verändern Deployment‑Modelle. Systeme, die zentralisierte Key‑Verteilung nutzen (z. B. PKI‑Gateways mit viel Speicher), kommen mit Classic McEliece klar. Dezentrale, speicherarme Geräte nicht.

Empfehlungen: Auswahlkriterien & Migrationstipps

Wer eine Entscheidung treffen oder Migration planen muss, sollte pragmatisch vorgehen. Hier sind bewährte Kriterien, gewichtet nach Risiko‑ und Betriebsanforderungen:

  1. Betriebsumgebung prüfen: CPU‑Architektur, verfügbare RAM/Flash, Energiebudget. Kleine Keys → Kyber. Sehr konservative Langzeit‑Archivierung → Classic McEliece.
  2. Messbarkeit: Führe Benchmarks auf Zielhardware durch (liboqs speed_kem), dokumentiere Compiler, Flags und liboqs‑Commit. Ohne reproduzierbare Messwerte bleibt die Auswahl spekulativ.
  3. Fehlerquoten validieren: Starte mit KATs und Stresstests; messe Fehlerraten über große N. Für design‑angegebene DFRs (z. B. bei Kyber) sind direkte experimentelle Verifikationen praktisch schwierig — deshalb Fokus auf Implementationsintegrität und Tests.
  4. Sicherheitshärtung: Prüfe constant‑time, nutze Side‑Channel‑Analysis und halte Implementationen gepatcht (z. B. CVE‑Fixes). Nutze static analysis und Fuzzing für KEM/Decap‑Pfad.
  5. Hybride Strategien: Erwäge Hybrid‑Handshake (klassisch + PQC) für schrittweise Migration. Das erhöht kurzfristig die Bandbreite, reduziert aber Migrationsrisiken.

Konkretes Vorgehen für Entwicklerteams: 1) Prototyp mit liboqs auf Zielplattform erstellen; 2) automatisierte Tests inkl. KATs und Timing‑Checks in CI; 3) Rolling‑Deploy mit Canary‑Monitoring und Telemetrie für Decapsulation‑Fehler; 4) Dokumentation aller Build‑Parameter und Backout‑Pläne.

Für Entscheider gilt: Budget für Speicher und Monitoring einplanen. Classic McEliece kann höhere TCO durch Storage/Distribution verursachen; Kyber erfordert weniger Bandbreite, dafür Aufmerksamkeit bei Implementations‑Patches.

Kurz: Keine Patentlösung. Messen, härten, schrittweise einführen — und immer aktuelle liboqs‑Releases und Security‑Advisories verfolgen.


Fazit

Kyber (Lattice) punktet mit kompakten Schlüsseln und guter Performance auf modernen CPUs — ideal für Bandbreiten‑ und Speicherkritische Anwendungen. Classic McEliece bietet konservative, langzeitige Sicherheit, verlangt aber deutlich mehr Speicher für Public Keys. Theoretische Failure‑Raten sind hilfreich zur Einordnung, experimental valide Messungen setzen jedoch reproduzierbare Testbeds voraus.

Wichtig für alle: Immer gepatchte Implementationen, KATs und Plattform‑spezifische Benchmarks nutzen. Migration gelingt schrittweise mit Hybriden und solidem Monitoring.


*Diskutiert eure Erfahrungen in den Kommentaren und teilt den Beitrag in den sozialen Medien!*

Artisan Baumeister

Mentor, Creator und Blogger aus Leidenschaft.

Für dich vielleicht ebenfalls interessant …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert