Elektrotechnik Bericht

Quantencomputer Sicherheit: Post-Quantum Cryptography für Entwickler

Technischer Leitfaden für Post-Quantum Cryptography und pragmatische PQC Migration in realen Systemen

Was du in diesem Artikel lernst

Inhaltsverzeichnis

Warum Entwickler jetzt handeln müssen

Klassische Public-Key-Verfahren wie RSA und ECC können durch Quantenalgorithmen langfristig gebrochen werden. Wer heute nur klassisch verschlüsselt, riskiert, dass sensible Daten später entschlüsselt werden. Genau darum geht es bei Quantencomputer Sicherheit.

Hinweis: Dieser Artikel bleibt technisch, aber bewusst praxisnah für Entwicklerteams in App-, Backend- und Infrastrukturprojekten.

Grundlagen: Was macht Quantencomputer gefährlich?

Ein Quantencomputer ist kein klassischer Prozessor mit schnelleren Transistoren, sondern ein physikalisches Rechensystem. Er nutzt gezielt quantenmechanische Zustände von Teilchen (z. B. Elektronenspin, supraleitende Schaltkreise oder Photonen), um Information zu verarbeiten.

Rechnen auf Quantenhardware bedeutet also: Zustand präparieren, mit einer Gate-Sequenz transformieren, dann messen. Viele Algorithmen werden mehrfach ausgeführt, um aus probabilistischen Messungen ein belastbares Resultat zu gewinnen.

Praktisch zentral ist die Dekohärenz: Qubits verlieren durch Störungen schnell ihre Information. Deshalb sind Fehlerkorrektur, tiefe Temperaturen und sehr präzise Kontrolle nötig. Genau diese technische Hürde ist der Hauptgrund, warum leistungsfähige Quantenangriffe noch nicht breit verfügbar sind.

Quantencomputer nutzen quantenmechanische Zustände direkt als Rechenressource. Ein Qubit kann in Superposition mehrere Zustände gleichzeitig repräsentieren, und Qubits können durch Verschränkung gekoppelt sein.

Shor löst Faktorisierung und diskrete Logarithmen effizienter als klassische Verfahren. Damit geraten RSA, DH/ECDH und ECDSA unter Druck. Grover beschleunigt brute-force Suche, wodurch sich die effektive Sicherheit symmetrischer Schlüssel reduziert.

Warum der Shor-Algorithmus so gefährlich ist

Die Sicherheit von RSA basiert darauf, dass die Zerlegung einer grossen Zahl N = p · q in ihre Primfaktoren p und q mit klassischen Computern extrem aufwändig ist. Für genügend grosse Schlüssellängen ist das in der Praxis nicht realistisch durchführbar.

Der Shor-Algorithmus greift dieses Problem nicht einfach mit mehr Rechenleistung an, sondern mit einer anderen mathematischen Strategie. Er reduziert die Faktorisierung auf ein Periodenfindungsproblem. Statt direkt die Faktoren von N zu suchen, betrachtet man eine Funktion der Form:

f(x) = a^x mod N

Dabei ist a eine zufällig gewählte Zahl, die zu N teilerfremd ist. Diese Funktion ist periodisch. Das bedeutet: Es gibt ein kleinstes r, sodass wieder derselbe Zustand erreicht wird:

a^r ≡ 1 mod N

Dieses r ist die gesuchte Periode. Genau hier liegt der Kern des Algorithmus: Wenn diese Periode bekannt ist, lassen sich mit hoher Wahrscheinlichkeit die Faktoren von N berechnen.

Wie aus der Periode die Faktoren entstehen

Wenn die gefundene Periode r gerade ist und zusätzlich gilt, dass a^(r/2) nicht trivial ist, können Kandidaten für die Faktoren über den grössten gemeinsamen Teiler berechnet werden:

gcd(a^(r/2) - 1, N)
gcd(a^(r/2) + 1, N)

Ergeben diese Ausdrücke nichttriviale Teiler von N, ist die Faktorisierung gelungen. Genau dieser Schritt ist mathematisch elegant: Aus der Struktur der modularen Exponentialfunktion wird direkt Information über die Primfaktoren gewonnen.

Warum das klassisch schwer ist

Klassische Faktorisierungsverfahren wie das Number Field Sieve wachsen mit der Schlüssellänge sehr ungünstig. Für RSA-2048 führt das zu einem praktisch unbeherrschbaren Aufwand. Das Problem ist nicht, dass ein einzelner Schritt kompliziert wäre, sondern dass der gesamte Suchraum enorm ist.

Auch das Finden der Periode ist auf klassischen Rechnern nicht effizient lösbar. Genau hier setzt die Quantenmechanik an: Ein Quantencomputer kann viele Zustände gleichzeitig in einer Superposition verarbeiten und die Periodizität mit einer Quanten-Fourier-Transformation (QFT) sichtbar machen.

Vereinfachter Ablauf des Shor-Algorithmus

1. Eine Zahl a wählen, die teilerfremd zu N ist.
2. Die Funktion f(x) = a^x mod N auf vielen Zuständen gleichzeitig auswerten.
3. Die Periodeninformation mit einer Quanten-Fourier-Transformation extrahieren.
4. Aus dem Messergebnis die Periode r rekonstruieren.
5. Mit r nichttriviale Faktoren von N berechnen.

Warum das für RSA und ECC kritisch ist

RSA basiert auf Faktorisierung. ECC und klassische Diffie-Hellman-Verfahren basieren auf dem diskreten Logarithmusproblem. Der Shor-Algorithmus kann beide Problemklassen effizient angreifen. Das macht ihn so gefährlich: Er beschleunigt klassische Angriffe nicht nur ein wenig, sondern ändert die mathematische Schwierigkeitsklasse des Problems.

Für Entwickler bedeutet das: Die Sicherheit von RSA, ECDSA, ECDH und ähnlichen Verfahren ist nicht langfristig stabil, sobald ausreichend grosse fehlerkorrigierte Quantencomputer verfügbar werden.

Zeithorizont realistisch einordnen

Es gibt keinen exakten Termin für praktisch einsetzbare Quantenangriffe auf grosse Produktivsysteme. Realistisch ist ein Unsicherheitsfenster von etwa 10 bis 20 Jahren für breite Relevanz, mit früheren Teilrisiken in speziellen Szenarien.

• Technischer Fortschritt ist schnell, aber hardwareseitig weiterhin schwierig.
• Normen und Migrationspfade sind bereits definiert (NIST, CNSA).
• Die Vorlaufzeit für sichere Migration ist meist länger als ein einzelner Release-Zyklus.

Post-Quantum Cryptography: Standards und Auswahl

Post-Quantum Cryptography (PQC) bezeichnet Algorithmen, die auf klassischen Rechnern laufen und nach heutigem Stand gegen bekannte Quantenangriffe resistent sind. Für Teams bedeutet das: jetzt Architektur und Protokolle auf Austauschbarkeit vorbereiten.

Werte sind absichtlich grob gehalten; konkrete Parameter hängen von Sicherheitsstufe und Implementierung ab.

Was bedeutet das für klassische Verfahren?

Für klassische Public-Key-Verfahren ist der Unterschied dramatisch: Ein ausreichend leistungsfähiger Quantencomputer könnte RSA-2048 oder ECC nicht nur etwas schneller, sondern grundlegend effizienter angreifen. NIST beschreibt das sehr anschaulich: Was für klassische Computer Milliarden Jahre dauern würde, könnte für einen kryptografisch relevanten Quantencomputer auf Stunden oder Tage schrumpfen.

Bei symmetrischer Kryptografie ist die Lage besser: AES wird durch bekannte Quantenalgorithmen nicht direkt gebrochen, aber Grovers Algorithmus reduziert die effektive Sicherheit ungefähr auf die Quadratwurzel des ursprünglichen Suchraums. Vereinfacht bedeutet das: AES-256 verhält sich unter Quantenangriffen eher wie ca. 128 Bit Sicherheit - und gilt damit weiterhin als sehr stark, während AES-128 deutlich weniger Reserve bietet. Deshalb empfehlen NIST und NSA für langfristigen Schutz den Einsatz von PQC für Public Key, kombiniert mit AES-256 sowie SHA-384 oder SHA-512 für zusätzliche Sicherheitsreserve.

Komplexitätsvergleich: klassisch vs. Quanten

Der entscheidende Unterschied zwischen klassischen und quantenbasierten Angriffen liegt nicht nur in der Geschwindigkeit, sondern in der Komplexitätsklasse des zugrunde liegenden Problems.

Ein Algorithmus gilt als praktisch sicher, wenn der Rechenaufwand mit steigender Schlüssellänge sehr schnell wächst – typischerweise exponentiell oder sub-exponentiell. Genau darauf basiert die Sicherheit heutiger Kryptografie.

RSA-Faktorisierung im Vergleich

Für RSA basiert die Sicherheit auf der Schwierigkeit, eine grosse Zahl N = p · q zu faktorisieren.

Das Wachstum ist extrem schnell. Schon kleine Erhöhungen der Schlüssellänge führen zu massiv höherem Rechenaufwand.

Das ist der entscheidende Unterschied:

• Klassisch: Aufwand wächst extrem schnell → praktisch unlösbar
• Quanten: Aufwand wächst moderat → praktisch lösbar

Symmetrische Kryptografie (AES) im Vergleich

Symmetrische Verfahren wie AES werden nicht durch Shor, sondern durch Grovers Algorithmus beeinflusst.

• Klassisch: Aufwand = 2ⁿ
• Quanten (Grover): Aufwand ≈ 2^n/2

Das bedeutet:

• AES-128 → effektiv ~64 Bit Sicherheit (kritisch)
• AES-256 → effektiv ~128 Bit Sicherheit (weiterhin stark)

Hash-Funktionen

Auch Hash-Funktionen sind betroffen, allerdings weniger kritisch:

• Preimage-Angriff: von 2ⁿ → 2^n/2
• Kollisionsangriff bleibt bei ~2^n/2

Daher gelten:

• SHA-256 → reduziert, aber noch brauchbar
• SHA-384 / SHA-512 → empfohlen für langfristige Sicherheit

Warum dieser Unterschied so entscheidend ist

Die Sicherheit moderner Kryptografie basiert auf der Annahme, dass bestimmte Probleme nicht effizient lösbar sind.

Quantencomputer ändern genau diese Annahme:

• Faktorisierung → effizient lösbar
• Diskreter Logarithmus → effizient lösbar

Damit fallen die mathematischen Grundlagen vieler bestehender Systeme weg.

Warum gitterbasierte Kryptografie als quantensicher gilt

Moderne Post-Quantum-Verfahren wie Kyber (ML-KEM) und Dilithium (ML-DSA) basieren nicht auf Faktorisierung oder diskreten Logarithmen, sondern auf Problemen aus der linearen Algebra – genauer: auf Gittern (Lattices).

Ein Gitter kann man sich vereinfacht als ein regelmässiges Punkteraster im mehrdimensionalen Raum vorstellen. Jeder Punkt ist eine Kombination aus Basisvektoren.

Grundidee: Rechnen mit verrauschten Gleichungen

Das zentrale Problem hinter vielen PQC-Verfahren ist Learning With Errors (LWE).

Dabei wird ein lineares Gleichungssystem absichtlich mit Rauschen versehen:

b = A · s + e

• A → bekannte Matrix
• s → geheimer Vektor (gesuchter Schlüssel)
• e → zufälliges Rauschen (kleine Fehler)

Ziel ist es, aus A und b den geheimen Vektor s zu rekonstruieren.

Warum ist das schwer?

Ohne Rauschen wäre das ein normales lineares Gleichungssystem und leicht lösbar. Durch das Rauschen wird das Problem jedoch instabil:

• Kleine Fehler verfälschen jede Gleichung
• Viele Lösungen erscheinen plausibel
• Der Suchraum wird extrem gross

Das Problem entspricht geometrisch der Suche nach einem Punkt im Gitter, der „nahe genug“ an einem verrauschten Zielpunkt liegt.

Warum auch Quantencomputer hier nicht helfen

Für Probleme wie Faktorisierung existiert mit Shor ein effizienter Quantenalgorithmus. Für Gitterprobleme wie LWE gilt das aktuell nicht.

Die besten bekannten Angriffe – sowohl klassisch als auch quantenbasiert – haben weiterhin sehr hohen Aufwand.

• Keine bekannte polynomielle Lösung
• Angriffe bleiben exponentiell oder sub-exponentiell
• Parameter können gezielt erhöht werden

Vom LWE zu echten Verfahren (Kyber / Dilithium)

In der Praxis werden optimierte Varianten verwendet, z. B.:

• Ring-LWE (RLWE)
• Module-LWE (MLWE)

Diese reduzieren Speicherbedarf und erhöhen die Effizienz, ohne die Sicherheitsannahmen wesentlich zu verändern.

• Kyber → basiert auf Module-LWE (für Schlüsselaustausch)
• Dilithium → basiert ebenfalls auf Gitterproblemen (für Signaturen)

Warum diese Verfahren grösser sind

Ein Nachteil von PQC ist die grössere Datenmenge:

• Grössere öffentliche Schlüssel
• Grössere Ciphertexts
• Grössere Signaturen

Das liegt daran, dass viele Vektoren und Matrizen gespeichert werden müssen, anstatt nur einzelne Zahlen wie bei RSA oder ECC.

Einfaches Beispiel (stark vereinfacht)

Ein minimalistisches Konzept könnte so aussehen:

# stark vereinfacht – nur zur Illustration
        
        import numpy as np
        
        A = np.random.randint(0, 100, (3,3))
        s = np.random.randint(0, 10, (3,1))
        e = np.random.randint(-1, 2, (3,1))  # kleines Rauschen
        
        b = A @ s + e
        
        print("A:", A)
        print("b:", b)
        
        # Angreifer sieht nur A und b → s rekonstruieren ist schwer

Warum Entwickler darauf setzen sollten

• Keine bekannten effizienten Quantenangriffe
• Standardisierung durch NIST
• Bereits in reale Systeme integrierbar

Für Entwickler bedeutet das: Die Zukunft der Public-Key-Kryptografie liegt sehr wahrscheinlich in gitterbasierten Verfahren.

Konkrete Angriffsszenarien mit Quantencomputern

Die Bedrohung durch Quantencomputer ist nicht nur theoretisch. In vielen Systemen existiert bereits heute ein reales Risiko – vor allem durch das Prinzip „harvest now, decrypt later“.

Angriffsszenario 1: Aufgezeichnete TLS-Verbindungen

Ein Angreifer zeichnet heute verschlüsselte Verbindungen auf, z. B. HTTPS-Traffic.

• 2026: TLS-Verbindung wird mit RSA oder klassischem ECDH aufgebaut
• Angreifer speichert den gesamten Traffic
• 2035+: Quantencomputer verfügbar
• → nachträgliche Entschlüsselung möglich

Selbst wenn die Daten heute sicher erscheinen, kann ihre Vertraulichkeit in der Zukunft komplett verloren gehen.

Angriffsszenario 2: Fehlende Forward Secrecy

Wenn kein Forward Secrecy verwendet wird, ist das Risiko noch höher.

• Server verwendet statischen RSA-Schlüssel
• Angreifer erhält später den privaten Schlüssel
• → alle alten Verbindungen können entschlüsselt werden

Allerdings: Forward Secrecy schützt nicht gegen Quantenangriffe auf den Schlüsselaustausch selbst.

Angriffsszenario 3: Signaturen und Software-Updates

Digitale Signaturen sichern heute Software-Updates, Firmware und Container-Images.

• Code wird mit ECDSA signiert
• Public Key ist öffentlich bekannt
• Quantencomputer berechnet privaten Schlüssel
• → Angreifer kann gültige Signaturen erzeugen

Das betrifft insbesondere:

• IoT-Geräte
• Industrieanlagen
• Software-Lieferketten (Supply Chain)

Angriffsszenario 4: VPN und langfristige Schlüssel

Viele VPN-Systeme verwenden langfristige Schlüssel oder Zertifikate.

• Angreifer zeichnet verschlüsselten Traffic auf
• Schlüssel werden später gebrochen
• → gesamte Kommunikation rekonstruierbar

Besonders kritisch:

• Behördenkommunikation
• Industriegeheimnisse
• medizinische Daten

Angriffsszenario 5: PKI-Infrastruktur

Die gesamte Public-Key-Infrastruktur basiert auf vertrauenswürdigen Zertifikaten.

• Root-CA verwendet RSA oder ECC
• Quantencomputer kompromittiert den privaten Schlüssel
• → komplette Zertifikatskette wird unsicher

Warum diese Szenarien heute schon relevant sind

Der kritische Punkt ist die Lebensdauer der Daten.

• Kurzlebige Daten → geringes Risiko
• Langfristig vertrauliche Daten → hohes Risiko

Fazit für Entwickler

Die grösste Gefahr ist nicht der Angriff von morgen, sondern die Verzögerung der Migration.

• Angreifer sammeln heute Daten
• Angriffe erfolgen in der Zukunft

Performance und Trade-offs von Post-Quantum-Kryptografie

Post-Quantum-Kryptografie ist nicht einfach ein „Drop-in-Replacement“ für RSA oder ECC. Sie bringt reale technische Auswirkungen auf Performance, Speicher und Netzwerk mit sich.

Grössenvergleich: klassische vs. PQC-Verfahren

Die Grössenunterschiede wirken sich direkt auf Netzwerkprotokolle und Speicherbedarf aus.

Auswirkungen auf TLS und Netzwerk

Grössere Schlüssel und Signaturen führen zu:

• Grösseren TLS-Handshakes
• Mehr Netzwerkpaketen
• Höherer Latenz bei Verbindungsaufbau

Beispiel:

• ECDSA-Zertifikat → wenige hundert Bytes
• Dilithium-Zertifikat → mehrere Kilobyte

Das kann insbesondere relevant sein für:

• Mobile Netzwerke
• IoT-Geräte
• High-Frequency APIs

CPU- und Rechenaufwand

PQC ist nicht immer langsamer – aber anders verteilt:

• Key Generation → oft teurer
• Signieren → moderat
• Verifikation → teilweise schneller als klassische Verfahren

Das bedeutet:

• Server mit vielen Verifikationen profitieren teilweise
• Geräte mit wenig CPU können belastet werden

Speicher- und Infrastrukturkosten

Durch grössere Schlüssel entstehen zusätzliche Anforderungen:

• Mehr RAM für Schlüssel und Buffers
• Grössere Zertifikate in PKI-Systemen
• Mehr Speicherbedarf in Datenbanken

Hybrid-Kryptografie als Übergangslösung

In der Praxis wird aktuell meist ein hybrider Ansatz verwendet:

• Klassisch (z. B. X25519)
• +
• PQC (z. B. Kyber)

Beide Schlüssel werden kombiniert, sodass Sicherheit gegen beide Angriffsmodelle besteht.

Typische Fehler in der Praxis

• PQC ohne Performance-Tests einsetzen
• Handshake-Grösse unterschätzen
• Keine Fallback-Strategie implementieren
• Krypto-Agilität nicht berücksichtigen

Engineering-Empfehlungen

• Immer Benchmarks durchführen (TLS, API, Load)
• Hybrid-Krypto zuerst in Staging testen
• Bandbreite und Latenz messen
• Speicherverbrauch im Auge behalten

Threat Model: Wer greift dich an und was ist realistisch?

Sicherheitsentscheidungen sind nur sinnvoll, wenn klar ist, gegen wen man sich schützt. Im Kontext von Quantencomputern unterscheiden sich Angreifer stark in ihren Fähigkeiten, Zeithorizonten und Ressourcen.

Angreiferklassen

1. Passiver Angreifer (Traffic Capture)

Der einfachste, aber oft unterschätzte Angreifer:

• zeichnet verschlüsselten Traffic auf
• greift nicht aktiv ein
• wartet auf zukünftige Entschlüsselungsmöglichkeiten

Dieser Angreifer ist heute bereits realistisch (z. B. Internet-Backbone, staatliche Akteure).

2. Aktiver Angreifer (MITM)

Ein aktiver Angreifer kann Verbindungen manipulieren:

• führt Man-in-the-Middle-Angriffe durch
• erzwingt schwächere Algorithmen
• nutzt Implementierungsfehler aus

Mit Quantencomputern kann dieser Angreifer zusätzlich:

• Schlüssel rekonstruieren
• Verbindungen aktiv entschlüsseln

3. Staatlicher Akteur (High-End Angreifer)

Der relevanteste Gegner im Kontext von Quantencomputern:

• verfügt über grosse Rechenressourcen
• kann Daten über Jahre speichern
• hat Zugriff auf zukünftige Technologien

Angriffsziele

Nicht alle Daten sind gleich kritisch. Entscheidend ist die Schutzdauer.

• Kurzfristig (Minuten–Tage): geringes Risiko
• Mittelfristig (Monate–Jahre): moderates Risiko
• Langfristig (10+ Jahre): hohes Risiko

Wann ist PQC wirklich notwendig?

Eine einfache Entscheidungsregel für Entwickler:

if (Schutzdauer > Zeit_bis_Quantencomputer):
    PQC jetzt einführen
else:
    Migration planen

Dabei ist „Zeit bis Quantencomputer“ bewusst unscharf – genau das macht die Planung schwierig.

Typische Fehlannahmen

• „Quantencomputer sind noch weit weg“ → Migration dauert länger als gedacht
• „Unsere Daten sind nicht interessant“ → oft falsch eingeschätzt
• „Forward Secrecy reicht“ → schützt nicht gegen alle Szenarien

Risikobewertung in der Praxis

Ein realistisches Modell kombiniert mehrere Faktoren:

• Datenwert
• Schutzdauer
• Angreiferfähigkeiten
• Systemexposition (Internet, internes Netz, IoT)

Daraus ergibt sich:

• High Risk: sofort PQC / Hybrid einsetzen
• Medium Risk: Migration vorbereiten
• Low Risk: beobachten und planen

Praktische Umsetzung: von der Theorie zum Prototyp

Post-Quantum-Kryptografie ist nicht nur ein theoretisches Forschungsthema, sondern bereits heute in Bibliotheken, Testumgebungen und ersten Integrationen verfügbar. Für Entwickler ist entscheidend, die Beispiele richtig einzuordnen:

• Didaktische Beispiele erklären das mathematische Prinzip
• PoC-Beispiele zeigen die API und den Ablauf
• Integrationsbeispiele zeigen, wie PQC in TLS, Services und Infrastruktur eingebunden wird

Didaktisches Beispiel: verrauschte lineare Gleichungen als Grundidee von LWE

Der folgende Code ist keine echte Kryptobibliothek, sondern nur eine vereinfachte Illustration der mathematischen Idee hinter gitterbasierten Verfahren. Er zeigt, warum ein lineares Gleichungssystem durch kleines Rauschen plötzlich schwer rekonstruierbar werden kann.

import numpy as np

# Didaktisches Beispiel: stark vereinfacht
# A = öffentliche Matrix
# s = geheimer Vektor
# e = kleines Rauschen
# b = beobachteter Wert

A = np.random.randint(0, 100, (3, 3))
s = np.random.randint(0, 10, (3, 1))
e = np.random.randint(-1, 2, (3, 1))

b = A @ s + e

print("Öffentliche Matrix A:")
print(A)
print("Beobachteter Vektor b:")
print(b)

# Ein Angreifer kennt hier nur A und b.
# Ohne Rauschen wäre s leicht berechenbar.
# Durch das zusätzliche Rauschen wird die Rekonstruktion deutlich schwieriger.

PoC-Beispiel: Post-Quantum-KEM und Signatur in Python mit liboqs

Dieses Beispiel zeigt einen minimalen Proof of Concept mit liboqs. Es eignet sich, um den grundlegenden Ablauf eines quantensicheren Schlüsselaustauschs und einer Signatur technisch zu verstehen:

• Schlüsselpaar erzeugen
• Shared Secret kapseln und entkapseln
• Nachricht signieren und verifizieren

Solche Tests sind besonders sinnvoll für frühe Evaluationsphasen in Backend-Diensten, Security-Gateways oder internen Toolchains.

import oqs

# -----------------------------
# 1) KEM / Schlüsselaustausch
# -----------------------------
# Ziel: Zwei Seiten erzeugen ein gemeinsames Shared Secret,
# ohne dass dieses direkt übertragen wird.

with oqs.KeyEncapsulation("Kyber768") as kem_alice:
    public_key = kem_alice.generate_keypair()

    # Die Gegenseite kapselt ein Shared Secret mit dem Public Key
    ciphertext, shared_secret_enc = kem_alice.encap_secret(public_key)

    # Die ursprüngliche Seite entkapselt das Secret wieder
    shared_secret_dec = kem_alice.decap_secret(ciphertext)

    assert shared_secret_enc == shared_secret_dec
    print("KEM erfolgreich: Shared Secret identisch")

# -----------------------------
# 2) Signatur / Authentizität
# -----------------------------
# Ziel: Eine Nachricht so signieren, dass ihre Echtheit
# und Unverändertheit verifiziert werden kann.

with oqs.Signature("Dilithium5") as sig:
    public_sig_key = sig.generate_keypair()

    message = b"Vertrauliche Nachricht"
    signature = sig.sign(message)

    valid = sig.verify(message, signature, public_sig_key)
    print("Signatur gueltig:", valid)

Integrationsbeispiel: PQC in Go mit CIRCL

Dieses Beispiel zeigt denselben Grundgedanken in Go. Es ist besonders interessant für Entwickler, die an Services, Gateways oder Sicherheitskomponenten arbeiten und PQC früh in bestehende Backend-Systeme integrieren möchten.

package main

import (
    "bytes"
    "crypto/rand"
    "fmt"

    "github.com/cloudflare/circl/kem/kyber/kyber1024"
)

func main() {
    // Schlüsselpaar für den KEM-Ablauf erzeugen
    pub, priv, err := kyber1024.GenerateKeyPair(rand.Reader)
    if err != nil {
        panic(err)
    }

    // Die "sendende" Seite kapselt ein Shared Secret
    ct, ssEnc := pub.Encapsulate(rand.Reader)

    // Die "empfangende" Seite entkapselt das Shared Secret
    ssDec := priv.Decapsulate(ct)

    if !bytes.Equal(ssEnc, ssDec) {
        fmt.Println("Fehler: Shared Secrets stimmen nicht überein")
        return
    }

    fmt.Println("KEM erfolgreich: Shared Secret identisch")
}

Integrationsbeispiel: Hybrid-TLS im Lab oder Staging

In der Praxis beginnt PQC-Migration selten direkt auf Anwendungsebene, sondern oft bei der Transportverschlüsselung. Ein sinnvoller erster Schritt ist deshalb eine hybride TLS-Testumgebung, in der klassische und post-quantenbasierte Verfahren parallel evaluiert werden.

Der folgende Abschnitt zeigt keinen vollständigen Produktions-Rollout, sondern einen typischen Lab-/Staging-Ansatz:

• OpenSSL mit PQC-Erweiterung prüfen
• hybride Gruppen konfigurieren
• Verbindungsaufbau und Interoperabilität testen

# Verfügbare Provider anzeigen
openssl list -providers

# Beispiel: OpenSSL-Konfiguration so setzen,
# dass ein PQC-Provider (z. B. oqsprovider) geladen wird
export OPENSSL_CONF=/etc/ssl/openssl.cnf

# Danach können in einer Testumgebung hybride Gruppen
# und PQ-fähige TLS-Konfigurationen geprüft werden.

Ein minimaler Python-Client für einen ersten Verbindungstest könnte so aussehen:

import ssl
import socket

# Starken TLS-Kontext aufbauen
context = ssl.create_default_context()
context.set_ciphers("TLS_AES_256_GCM_SHA384")

# Optional: hybride Gruppe aktivieren, falls lokal verfügbar
# Achtung: Syntax und Verfügbarkeit hängen stark vom Build ab
# context.set_ecdh_curve("X25519:MLKEM768")

with context.wrap_socket(socket.socket(), server_hostname="example.com") as conn:
    conn.connect(("server.example.com", 8443))
    conn.send(b"GET / HTTP/1.0\r\nHost: example.com\r\n\r\n")
    response = conn.recv(4096)
    print(response.decode(errors="ignore"))

Was du bei PQC-Code praktisch testen solltest

Der eigentliche Mehrwert von PQC-Prototypen entsteht nicht durch das reine „Laufen lassen“ der Bibliothek, sondern durch gezielte technische Tests.

• API-Stabilität: Wie ändern sich Bibliotheken und Parameternamen?
• Performanz: Wie hoch sind CPU-Zeit, RAM-Verbrauch und Latenz?
• Handshake-Grösse: Wie stark wachsen Schlüssel, Ciphertexts und Zertifikate?
• Fehlerpfade: Was passiert bei nicht unterstützten Gruppen oder Versionen?
• Interoperabilität: Funktionieren Clients, Server, Proxies und Load-Balancer gemeinsam?

PQC-Migrationscheckliste für Teams

Eine erfolgreiche PQC-Migration beginnt nicht mit dem sofortigen Austausch aller Algorithmen, sondern mit einer sauberen technischen Bestandsaufnahme und einem kontrollierten Einführungsplan. Die folgende Checkliste ist für Entwickler, Architekten und Infrastrukturteams gedacht.

Migrationsfluss (visuell)

Der folgende Ablauf zeigt die typische Reihenfolge einer technisch sauberen Migration: zuerst Sichtbarkeit schaffen, dann Risiken priorisieren, anschliessend hybride Verfahren testen und erst danach kontrolliert ausrollen.

Was passiert, wenn du nichts machst?

Der Verzicht auf eine PQC-Strategie bedeutet nicht nur ein zukünftiges Kryptorisiko, sondern auch ein architektonisches und betriebliches Risiko.

Der gefährlichste Fehler ist daher nicht, heute noch klassische Verfahren zu betreiben, sondern die Migration so lange aufzuschieben, bis sie unter Zeitdruck und ohne saubere Architektur nachgeholt werden muss.

Fazit und nächste Schritte für Entwickler

Quantencomputer sind keine abstrakte Zukunftsidee mehr, sondern ein realer Planungsfaktor für die Kryptografie moderner Systeme. Die eigentliche Gefahr liegt nicht darin, dass morgen plötzlich jede Verschlüsselung gebrochen wird, sondern darin, dass heutige Sicherheitsannahmen für Public-Key-Verfahren langfristig nicht mehr stabil sind.

Technisch ist der Unterschied fundamental: Klassische Kryptografie wie RSA und ECC basiert auf mathematischen Problemen, die für klassische Computer praktisch unlösbar sind. Quantenalgorithmen wie Shor verändern diese Annahme grundlegend. Gleichzeitig zeigen Post-Quantum- Verfahren wie ML-KEM und ML-DSA, dass quantensichere Alternativen auf klassischer Hardware bereits heute implementierbar sind – allerdings mit realen Trade-offs bei Schlüssellängen, Signaturgrössen, Netzwerk-Overhead und Integrationsaufwand.

Für Entwickler und Architekten bedeutet das: Die wichtigste Aufgabe ist nicht der sofortige Komplettumbau aller Systeme, sondern der Aufbau von Krypto-Agilität. Wer Algorithmen austauschbar macht, hybride Verfahren testet, den Schlüssellifecycle sauber verwaltet und seine kritischen Datenflüsse kennt, schafft die Grundlage für eine kontrollierte PQC-Migration.

Der sinnvollste nächste Schritt ist deshalb klar:

• bestehende kryptografische Abhängigkeiten inventarisieren
• langfristig schützenswerte Daten identifizieren
• hybride PQC-Prototypen in Staging aufbauen
• Performance, Interoperabilität und Rollback-Pfade testen

Wer diese Schritte heute einleitet, reduziert nicht nur das zukünftige Risiko, sondern verhindert auch, dass die eigene Organisation später unter hohem Zeitdruck migrieren muss.

Quellen und Hinweise

Die Empfehlungen in diesem Bericht orientieren sich an öffentlichen Leitfäden und Veröffentlichungen von NIST, NSA/CNSA, BSI, IETF und dem Open-Quantum-Safe-Umfeld.

Lizenzhinweis: Die gezeigten Codebeispiele basieren auf Open-Source-Bibliotheken (z. B. liboqs: MIT, CIRCL: BSD-3-Clause). Beispiele sind vereinfacht und dienen zur Illustration. Für Produktivbetrieb sind Security-Reviews, HSM-Strategie, Schlüssellifecycle und regelmässige Updates zwingend.