Post-Quanten-SSH und -TLS

Post-Quanten-Kryptografie war ein Jahrzehnt lang ein Konferenzthema und wurde dann, ohne dass es jemand angekündigt hätte, zur Voreinstellung auf Ihrem Notebook. Wer OpenSSH 10 und einen Browser aus den letzten zwei Jahren betreibt, überträgt den Großteil seines Verkehrs bereits gegen einen Quantenangreifer geschützt. Was bleibt, ist eng umrissen, unspektakulär und sehr konkret: die Verbindungen zu finden, die zurückgeblieben sind. Dieser Text beschreibt, wie das auf echter Infrastruktur geht – was zu prüfen ist, was zu ändern, wie man es hinterher verifiziert und welchen Teil des Problems man bewusst noch nicht anfassen sollte.

Beherrschbar wird das Ganze durch eine Trennung. Kryptografie schützt Verbindungen auf zwei Wegen: über den Schlüsselaustausch, der das Geheimnis für die Sitzungsverschlüsselung festlegt, und über Signaturen, die belegen, mit wem Sie sprechen. Ein Quantencomputer bricht beides. Dringend ist heute aber nur eines von beiden, und die Verwechslung der beiden ist der Grund, warum so viele Post-Quanten-Programme in einer Tabelle stecken bleiben. Alles Folgende ergibt sich aus dieser Unterscheidung.

Wo die Post-Quanten-Kryptografie 2026 tatsächlich steht

Der Schlüsselaustausch ist erledigt. Nicht geplant, nicht im Pilotbetrieb – veröffentlicht, als Standard gesetzt und im Einsatz. OpenSSH bietet post-quantensicheren Schlüsselaustausch seit Version 9.0 vom April 2022, und seit OpenSSH 10.0 im April 2025 ist der Hybrid mlkem768x25519-sha256 der voreingestellte Algorithmus. OpenSSL 3.5.0, einen Tag zuvor erschienen, hat seine Standardliste der unterstützten TLS-Gruppen so geändert, dass hybride Post-Quanten-Gruppen enthalten und bevorzugt sind, und bietet nun X25519MLKEM768 als Standard-Keyshare an. Wer eines der beiden Pakete im letzten Jahr aktualisiert hat, hat das eingeschaltet, ohne etwas zu tun.^{[ssh100][ossl35]}

Die Messungen bestätigen das Bild. Cloudflare veröffentlicht seit 2023 Zahlen zur Verbreitung des post-quantensicheren Schlüsselaustauschs, und die Kurve stieg binnen etwa zwei Jahren von einem Rundungsfehler auf die Mehrheit des menschlichen Web-Verkehrs. Schauen Sie die Live-Zahl nach, statt einem Artikel zu vertrauen – auch diesem nicht. Entscheidend ist nicht der exakte Prozentwert, sondern die Form der Kurve: Sie sagt Ihnen, dass die Nachzügler inzwischen eine endliche, aufzählbare Menge sind und nicht mehr das halbe Internet.^{[cfpq][cfradar]}

Bei den Signaturen ist es genau umgekehrt. NIST hat ML-DSA und SLH-DSA 2024 standardisiert, Implementierungen existieren, und nichts davon lässt sich im öffentlichen Web einsetzen. Ein Zertifikat nützt nur, wenn die prüfende Gegenstelle der signierenden Wurzel bereits vertraut – und in den Trust Stores der Browser liegt keine Post-Quanten-Wurzel. Das ist kein vorübergehendes Verpackungsproblem, um das man herumkonstruieren könnte, sondern eine Frage der Reihenfolge im Ökosystem, und die braucht Jahre.

Store now, decrypt later – und was dieser Angriff nicht abdeckt

Warum der Schlüsselaustausch dringend ist und die Signaturen nicht, liegt an einer einzigen Asymmetrie, die OpenSSH klarer formuliert als das meiste Herstellermaterial:^[pq]

Die gesamte Vertraulichkeit einer SSH-Verbindung hängt am kryptografischen Schlüsselaustausch. Kann ein Angreifer diesen brechen, kann er die vollständige Sitzung entschlüsseln und mitlesen. Er muss den Angriff nicht in Echtzeit ausführen: Er kann verschlüsselte SSH-Sitzungen heute sammeln und sie später entschlüsseln, sobald er Zugriff auf einen Quantencomputer hat.^[pq]

Das ist store now, decrypt later, ein rückwirkender Angriff. Eine heute auf der Leitung mitgeschnittene Sitzung mit klassischem Schlüsselaustausch ist eine dauerhafte Hypothek: Sie liegt im Archiv, bis ein kryptografisch relevanter Quantencomputer existiert, und öffnet sich dann. Nichts, was Sie 2032 tun, repariert eine 2026 aufgezeichnete Sitzung. Für Signaturen gibt es kein Gegenstück, denn eine nachträglich gefälschte Signatur erlaubt es nicht, sich rückwirkend in ein bereits geführtes Gespräch einzuschleichen. Daraus ergibt sich eine saubere Priorisierungsregel:

• Langlebige vertrauliche Daten über langlebige Strecken. Datenbankreplikation über WAN, Backup-Übertragungen, VPN-Tunnel zwischen Standorten, SSH-Sitzungen, in die Sie Zugangsdaten einfügen. Zuerst hier ansetzen: Die Nutzlast behält ihren Wert ein Jahrzehnt oder länger.
• Verkehr über nicht vertrauenswürdige Pfade. Alles, was Ihr Netz verlässt, und in einem ernsthaften Bedrohungsmodell alles, was das Backbone eines Cloud-Anbieters quert. Mitschneiden ist billig, wenn man die Position hat; Speichern ist noch billiger.
• Maschine-zu-Maschine-Strecken, an denen sich niemand anmeldet. Genau die übersieht das Audit, weil kein Mensch da ist, der eine Warnung sieht. Service Meshes, Message Queues, Replikationskanäle, Monitoring-Agenten.
• Kurzlebiger, geringwertiger, rein interner Verkehr. Ein Health Check zwischen zwei Pods auf demselben Knoten rechtfertigt kein Migrationsticket. Schreiben Sie das auf, damit die Ausnahme eine Entscheidung ist und kein Versehen.

Die Schätzungen, wann ein kryptografisch relevanter Quantencomputer verfügbar ist, reichen von fünf bis zwanzig Jahren; viele Beobachter erwarten die Mitte der 2030er. Sie müssen zu dieser Zahl keine Meinung haben. Sie müssen wissen, ob die Daten, die Sie heute übertragen, dann noch schützenswert sind – und für die meiste Infrastruktur lautet die ehrliche Antwort: ja.^[pq]

SSH in Ordnung bringen

SSH ist der einfache Gewinn und der richtige Einstieg, weil OpenSSH die schwierige Arbeit bereits erledigt hat. Es gibt kein Plugin, keinen Provider zu installieren, keinen experimentellen Zweig. Es gibt eine Versionsnummer und eine Konfigurationszeile, und beides ist dokumentiert.^{[ssh100][pq][ssh105][sshrel]}

In dieser Tabelle stecken zwei Fallen. Die erste ist der Name: Die Kurzform sntrup761x25519-sha512 existiert erst ab 9.9, davor muss die @openssh.com-Variante geschrieben werden – und sshd startet nicht, wenn es einen Namen nicht kennt. Die zweite ist tückischer. In der Standardliste zu stehen ist nicht dasselbe wie ausgewählt zu werden: In OpenSSH 8.9 ist das Post-Quanten-Verfahren zwar im voreingestellten KexAlgorithms enthalten, steht dort aber an sechster Stelle, unterhalb von curve25519-sha256. Jeder moderne Client handelt gegen einen solchen Server also einen klassischen Austausch aus, während der Server wahrheitsgemäß Post-Quanten-Unterstützung meldet. Genau deshalb besteht dieser Artikel darauf, das ausgehandelte Ergebnis zu lesen und nicht die Fähigkeitsliste.^{[ssh85][ssh99][ntru]}

Schritt 1: herausfinden, was tatsächlich ausgehandelt wird

Bevor Sie etwas ändern: messen. Der Unterschied, an dem die meisten scheitern, ist der zwischen unterstützt und ausgehandelt. Ein Server kann ML-KEM unterstützen und trotzdem einen klassischen Austausch abschließen, weil ein veralteter Client danach gefragt hat und die Präferenzliste des Servers es zuließ. Nur der ausgehandelte Algorithmus sagt Ihnen, ob eine konkrete Verbindung tatsächlich geschützt war.

# 1. Your client. Anything older than 8.5 has no post-quantum key agreement
#    at all; 8.5 through 9.8 have it only under the @openssh.com vendor name.
ssh -V
# OpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026

# 2. The remote server's software version, straight from the protocol banner.
ssh -v server.example.com exit 2>&1 | grep 'remote software version'
# debug1: Remote protocol version 2.0, remote software version OpenSSH_10.3

# 3. Which key agreement algorithms your local build even supports.
ssh -Q kex | grep -E 'mlkem|sntrup'
# mlkem768x25519-sha256
# sntrup761x25519-sha512

# 4. Supported is not preferred. On OpenSSH 8.9, for example, the PQ algorithm
#    is in the default list but sixth in it, so it is offered and never chosen:
ssh -G server.example.com | grep -i '^kexalgorithms'
# kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
# ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,...
#                                       ^ present, but nothing will ever pick it

# 5. The only answer that matters: what did THIS connection actually agree on?
#    Everything above is capability; this line is the negotiated result.
ssh -v server.example.com exit 2>&1 | sed -n 's/.*kex: algorithm: /negotiated: /p'
# negotiated: mlkem768x25519-sha256

Wer diese Zeile für einen Host lesen kann, kann sie für alle lesen. OpenSSH 10.1 hat clientseitig eine Warnung eingeführt, wenn eine Verbindung einen nicht post-quantensicheren Austausch aushandelt – hervorragend für Menschen und nutzlos für die automatisierten Strecken, die den Großteil einer realen Flotte ausmachen. Also selbst durchsuchen:^[ssh101]

#!/usr/bin/env bash
# pq-ssh-sweep.sh - classify every host in hosts.txt by negotiated key agreement.
# Read-only: it opens a connection, runs `exit`, and reads the debug output.
set -uo pipefail

while read -r host; do
  [ -z "$host" ] && continue
  # </dev/null matters: without it ssh swallows the rest of hosts.txt from the
  # loop's stdin and you silently audit only the first host.
  alg=$(ssh -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=accept-new \
        -v "$host" exit </dev/null 2>&1 | sed -n 's/.*kex: algorithm: //p' | head -1)
  case "$alg" in
    mlkem*)   printf '%-38s PQ-ML-KEM  %s\n' "$host" "$alg" ;;
    sntrup*)  printf '%-38s PQ-LEGACY  %s\n' "$host" "$alg" ;;
    "")       printf '%-38s UNREACHED  (auth, firewall or timeout)\n' "$host" ;;
    *)        printf '%-38s CLASSICAL  %s\n' "$host" "$alg" ;;
  esac
done < hosts.txt

# PQ-ML-KEM  -> done, nothing to do.
# PQ-LEGACY  -> safe today (sntrup761 is quantum-resistant) but not the NIST
#               standard; schedule the upgrade to OpenSSH 9.9+ anyway.
# CLASSICAL  -> this is your harvest-now-decrypt-later exposure. Fix first.

Schritt 2: die Konfiguration ändern, mit Bedacht

Mit der Bestandsaufnahme in der Hand ist die Änderung selbst klein. Legen Sie sie in eine Drop-in-Datei, statt die Hauptkonfiguration zu bearbeiten – so bleibt sie auffindbar, rücknehmbar und erkennbar Ihre:^{[sshdcfg][ssh99]}

# /etc/ssh/sshd_config.d/50-post-quantum.conf
# Requires `Include /etc/ssh/sshd_config.d/*.conf` in the main sshd_config,
# which Debian, Ubuntu, RHEL and Fedora already ship. Check with:
#   grep -r '^Include' /etc/ssh/sshd_config

# --- OpenSSH 9.9 and newer ---
# Post-quantum first, classical last. The list is ordered by preference, and
# the two hybrids are the only entries here that resist a quantum adversary.
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,curve25519-sha256@libssh.org

# --- OpenSSH 9.0 to 9.8: NEITHER name above exists on those builds. ---
# ML-KEM only arrived in 9.9, and until 9.9 the NTRU Prime hybrid existed
# solely under its vendor extension name. sshd refuses to start on an
# unknown algorithm name, so on those versions use exactly this line and
# nothing from the one above:
#   KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
# Confirm which names your build accepts before editing:  ssh -Q kex

# Signatures are NOT the urgent problem (see the article), but this is a good
# moment to drop the algorithms that are weak for classical reasons too.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# --- Validate BEFORE reloading, and keep your current session open. ---
#   sudo sshd -t && sudo systemctl reload ssh   # or sshd, depending on the distro
# Then open a SECOND session and confirm it works before closing the first.

Überspringen Sie das Validierungsritual nicht. Führen Sie sshd -t vor dem Reload aus, lassen Sie Ihre bestehende Sitzung offen und öffnen Sie eine zweite zur Bestätigung, bevor Sie die erste schließen. Ein Tippfehler in KexAlgorithms sperrt Sie aus, und auf einer Maschine ohne Konsolenzugang ist das kein Incident, sondern eine Neuinstallation.

Auf der Client-Seite können Sie strenger sein, weil ein lautes Scheitern auf dem eigenen Notebook verkraftbar ist, auf einem geteilten Bastion-Host dagegen nicht. Das Muster, das der Realität standhält, ist ein harter Standard plus explizite, datierte Ausnahmen:^[sshcfg]

# ~/.ssh/config - client side
#
# ssh_config is FIRST-OBTAINED-VALUE-WINS, not last. The specific block must
# come BEFORE `Host *`, otherwise the general block wins and the exception
# below is silently dead. This is the single most common mistake in hardened
# client configs, and it fails in the direction you will not notice.

# Exceptions first: the boxes you have not fixed yet. Make each one explicit
# and dated, so it shows up in review instead of quietly becoming permanent.
Host legacy-nas.internal jump-2019.example.com
    # TODO(2026-11-30): appliance firmware pending, ticket OPS-4471
    # Note this REPLACES the list rather than using `+`, which would append to
    # the full compiled-in default and quietly re-enable every modp group.
    KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
    WarnWeakCrypto no-pq-kex

# ...and the hard default for everything else.
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512
    WarnWeakCrypto yes

# Verify the result rather than trusting the file. `ssh -G` prints the
# effective configuration for a given destination, after all matching:
#   ssh -G legacy-nas.internal | grep -i '^kexalgorithms'
#   ssh -G anything-else.example.com | grep -i '^kexalgorithms'

Zwei Details, die man verinnerlichen sollte. Erstens sind alle von OpenSSH implementierten Post-Quanten-Verfahren Hybride: mlkem768x25519-sha256 führt ML-KEM zusammen mit X25519 aus und kombiniert beides. Sollte künftige Kryptoanalyse ML-KEM brechen, ist das Ergebnis nicht schwächer als der klassische Austausch von vorher. Es gibt keinen Fall, in dem Sie schlechter dastehen. Zweitens: Wer auf OpenSSH 9.x festsitzt, hat mit dem NTRU-Prime-Hybrid ab 9.0 ein quantenresistentes Verfahren – aber der Name ist entscheidend: vor 9.9 existiert es ausschließlich als sntrup761x25519-sha512@openssh.com, die Kurzform wird zurückgewiesen. Es ist nicht der NIST-Standard, aber es stoppt den Sammelangriff heute – und genau darum geht es.^[pq]

TLS in Ordnung bringen

TLS hat dieselbe Form mit einem anderen Hebel. Die Primitive liegen in OpenSSL, nicht in Ihrem Webserver: Mit OpenSSL 3.5 oder neuer brauchen Sie keine Patches, keinen oqs-provider, kein geforktes nginx. Prüfen Sie zuerst die Bibliothek, denn dort verstecken sich die meisten Überraschungen – eine Distribution kann ein aktuelles nginx ausliefern, das gegen ein OpenSSL gelinkt ist, das ML-KEM überhaupt nicht beherrscht.^{[ossl35][tlsdraft][mlkemkex]}

# 1. ML-KEM needs OpenSSL 3.5.0 or newer. No 3.x before 3.5 can do it at all,
#    however recent the rest of the stack looks.
openssl version
# OpenSSL 3.5.7 9 Jun 2026

# 2. Confirm the provider actually exposes the primitives.
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -iE 'ML-DSA|SLH-DSA'

# 3. What does a live endpoint negotiate when the client offers the hybrid?
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Negotiated TLS1.3 group|Protocol  :|Cipher    :'
# Negotiated TLS1.3 group: X25519MLKEM768

# 4. Control test: the same endpoint must still serve a classical-only client,
#    otherwise you have not hardened it, you have broken it.
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 -tls1_3 </dev/null 2>/dev/null \
  | grep 'Negotiated TLS1.3 group'
# Negotiated TLS1.3 group: X25519

Beachten Sie den Kontrolltest in Schritt vier. Das Aktivieren einer hybriden Gruppe soll klassische Clients nicht brechen; tut es das doch, haben Sie die Liste falsch konfiguriert und nicht gehärtet. Die Reihenfolge zählt, die Ausschließlichkeit nicht: Hybrid nach vorn, klassische Kurven dahinter stehen lassen.^[osslgroups]

# Pick the ONE stanza that matches your terminator - this is four different
# config syntaxes in one block, not a file you can paste as-is.

### nginx (built against OpenSSL 3.5+; no patches, no oqs-provider needed)
# ssl_ecdh_curve feeds the TLS supported-groups list. Hybrid first, then the
# classical curves that keep older clients working.
ssl_protocols       TLSv1.3 TLSv1.2;
ssl_ecdh_curve      X25519MLKEM768:X25519:secp256r1;
ssl_prefer_server_ciphers off;

### HAProxy 3.x
ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1

### Apache httpd (mod_ssl passes the list straight to OpenSSL)
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

### OpenSSL system-wide default, for everything that reads openssl.cnf
# [openssl_init] -> ssl_conf -> system_default
Groups = X25519MLKEM768:X25519:secp256r1

Die Konfiguration ist eine Zeile pro Server und speist in jedem Fall dieselbe OpenSSL-Gruppenliste:^{[nginxssl][haproxy][osslconf]}

Architektonisch wichtig ist nur eines: Das gilt dort, wo TLS terminiert wird. Terminiert ein CDN oder ein Load Balancer für Sie, ist das der Hop, der die hybride Gruppe braucht; die Konfiguration Ihres Origin ist eine eigene Frage – ebenso wie die Strecke dazwischen, und genau dieses interne Teilstück wird vergessen. Wer in Kubernetes terminiert, verortet das im Gateway, und die Migration weg von ingress-nginx ist der natürliche Moment dafür, weil Sie diese Objekte ohnehin neu schreiben.^[rfc8446]

Ein Inventar, das einer Prüfung standhält

Alles bisher Gesagte gilt pro Host. Was Prüfer – und Ihr künftiges Ich – wissen wollen, ist die Abdeckung: nicht „ist dieser Endpunkt in Ordnung“, sondern „wie viele gibt es und welche sind es nicht“. Bauen Sie die Liste aus der Quelle der Wahrheit, der Sie ohnehin vertrauen, und nicht aus einem Scan, damit Abwesenheit etwas bedeutet:

#!/usr/bin/env bash
# pq-inventory.sh - a starting point, not a CBOM. One line per listener, with
# the negotiated group, so the output diffs cleanly between runs.
set -uo pipefail
printf '%-34s %-9s %-22s %s\n' HOST PORT GROUP NOTE

while IFS=: read -r host port; do
  out=$(openssl s_client -connect "$host:$port" -servername "$host" \
        -groups X25519MLKEM768:X25519 -tls1_3 </dev/null 2>/dev/null)
  grp=$(printf '%s' "$out" | sed -n 's/^Negotiated TLS1.3 group: //p')
  sig=$(printf '%s' "$out" | sed -n 's/^Peer signature type: //p')
  case "$grp" in
    *MLKEM*) note="pq-ok" ;;
    "")      note="no-tls1.3-or-unreachable" ;;
    *)       note="classical-only" ;;
  esac
  printf '%-34s %-9s %-22s %s (sig %s)\n' "$host" "$port" "${grp:--}" "$note" "${sig:--}"
done < endpoints.txt

# endpoints.txt is one host:port per line. Feed it from whatever you already
# trust as the source of truth - the load balancer config, Consul, the CMDB -
# rather than from a network scan, so that absence is meaningful.

Widerstehen Sie dem Impuls, eine Cryptographic-Bill-of-Materials-Lösung zu kaufen, bevor Sie so etwas einmal laufen lassen haben. Die Werkzeuge werden wirklich besser, aber der erste Durchlauf lohnt sich von Hand, weil er Ihnen die Form Ihres eigenen Bestands zeigt – und genau das kann Ihnen kein Hersteller liefern. Reihenfolge:

1. Externe TLS-Terminierung. Jeder öffentliche Hostname. Kürzeste Liste, höchste Exposition, meist mit einer Änderung am Rand erledigt.
2. SSH, überall. Erst die Bastion-Hosts, dann alles, was von dort erreichbar ist. Hier taucht der lange Schwanz aus Appliances, Netzwerktechnik und vergessenen VMs auf.
3. Internes Service-zu-Service-TLS. Service Mesh, Datenbankverbindungen, Message Broker. Längere Liste, schwerer aufzuzählen – und der Ort, an dem die Standardwerte des Mesh das Problem eventuell schon gelöst haben.
4. VPN und Site-to-Site-Tunnel. Langlebig, hochwertig und häufig auf Hersteller-Firmware mit eigenem Zeitplan. Beginnen Sie das Gespräch mit dem Hersteller früh, denn das ist eher ein Beschaffungs- als ein technisches Problem.
5. Alles Eingebettete. Geräte, Agenten, Drucker, Kameras, Industriesteuerungen. Dokumentieren, das Risiko ausdrücklich akzeptieren und die Akzeptanz mit einem Datum versehen.

Halten Sie die Ausgabe vergleichbar und wiederholen Sie den Lauf regelmäßig. Eine Zahl, die sich in die falsche Richtung bewegt, ist das früheste Signal dafür, dass ein neu gebautes Image oder ein zurückgerolltes Paket die Arbeit stillschweigend rückgängig gemacht hat – ein weit häufigerer Fehler als eine misslungene Migration.

Signaturen und Zertifikate: warum Warten die richtige Entscheidung ist

Jetzt der Teil, in dem der nützliche Rat lautet: weniger tun. NIST hat 2024 zwei Post-Quanten-Signaturverfahren standardisiert, ML-DSA und SLH-DSA, beide sind in OpenSSL 3.5 implementiert. Sie können die Schlüssel heute erzeugen. In Ihre Zertifikatskette gehören sie nicht.^{[fips204][fips205][fips203]}

Der Grund ist derselbe, den OpenSSH für die Priorisierung des Schlüsselaustauschs anführt: Es gibt keinen „jetzt speichern, später fälschen“-Angriff. Eine Signatur muss nur in dem Moment unfälschbar sein, in dem sie geprüft wird. Die Dringlichkeit bei Signaturen betrifft nicht den heutigen Verkehr, sondern die Frage, ob klassische Signaturschlüssel außer Dienst gestellt sind, bevor es einen kryptografisch relevanten Quantencomputer gibt – eine Frist, die in Jahren gemessen wird, nicht in mitgeschnittenen Paketen.^[pq]

Die praktischen Blockaden haben die Form des Ökosystems, und keine davon können Sie auflösen:

• Browser vertrauen keiner Post-Quanten-Wurzel. Eine Zertifikatskette taugt nur so viel wie die Wurzel, der die Gegenstelle bereits vertraut, und diese Trust Stores bewegen sich aus guten Gründen im Mehrjahrestakt.
• Das Größenproblem ist real. ML-DSA-Signaturen und -Schlüssel sind deutlich größer als die von ECDSA. In einem Handshake, der die vollständige Kette überträgt, misst sich das auf verlustbehafteten Strecken in zusätzlichen Round Trips, nicht in abstrakten Bytes.
• OpenSSH hat nur ein experimentelles Post-Quanten-Signaturverfahren. Das Projekt entfernte die experimentelle XMSS-Unterstützung in 10.1 und ergänzte in 10.4 (Juli 2026) ein zusammengesetztes Verfahren mldsa44-ed25519, das ML-DSA-44 mit Ed25519 kombiniert. Es ist ausdrücklich experimentell und nicht standardmäßig aktiviert: Sie tragen es selbst in HostKeyAlgorithms und PubkeyAcceptedAlgorithms ein und erzeugen Schlüssel mit ssh-keygen -t mldsa44-ed25519. Gut zu wissen; noch nicht gut genug für produktive Host-Schlüssel.^{[ssh104][mldsased][ssh101]}
• Alle Zwischenstationen müssen mitspielen. An der Zertifikatsprüfung hängen Ihr Server, der Client, jede inspizierende Middlebox und jedes Pinning, das jemand 2019 eingebaut hat. Signaturen scheitern geschlossen – und für alle gleichzeitig.

Was also 2026 mit Signaturen tun? Zwei Dinge, beide billig. Verfahren ausmustern, die schon aus klassischen Gründen schwach sind: DSA ist in OpenSSH 10.0 vollständig entfallen, und SHA-1-Signaturen hätten längst weg sein sollen. Und die Zertifikatsausstellung automatisieren und kurzlebig machen, damit der Wechsel ein Konfigurationsschritt ist und kein Projekt, sobald Post-Quanten-Zertifikate ausstellbar werden. Krypto-Agilität ist kein Produkt, das man kauft, sondern die Eigenschaft, bereits schnell rotieren zu können – etwas, das Sie aus völlig anderen Gründen ohnehin wollen sollten. Hier gilt derselbe Instinkt wie bei langweiligen Architekturen: Die exotische Option ist nicht die sichere.^[ssh103]

Der regulatorische Kalender, korrekt wiedergegeben

Bei Fristen werden technische Artikel unbemerkt falsch, deshalb hier die sorgfältige Fassung. NIST IR 8547 – das Dokument, das alle für „RSA ist ab 2030 abgekündigt“ zitieren – ist ein Initial Public Draft vom November 2024. Die Kommentierungsfrist endete im Januar 2025, die eingegangenen Kommentare sind öffentlich. Es zeigt den erwarteten Ansatz von NIST und ist die richtige Planungsgrundlage, aber es als endgültigen, verbindlichen Standard zu zitieren ist unzutreffend – und jemand in Ihrem Review wird das wissen.^[ir8547]

Der Unterschied ist praktisch relevant: Ein Entwurf sagt Ihnen, wohin sich der Boden bewegt, und das genügt zum Planen. Es genügt nicht, um „von NIST gefordert“ in ein Designdokument zu schreiben. Zitieren Sie ihn als das, was er ist, und Ihr Programm übersteht sein erstes ernsthaftes Review.^[ir8547]

Europa geht einen parallelen Weg mit anderer Mechanik. Die Mitgliedstaaten haben über die NIS-Kooperationsgruppe einen koordinierten Umsetzungsfahrplan verabschiedet: Beginn der Umstellung und laufende Pilotprojekte bis Ende 2026, Hochrisiko-Anwendungsfälle und kritische Infrastrukturen bis 2030, im praktisch Möglichen abgeschlossen bis 2035. Es ist ein Koordinierungsinstrument und keine Verordnung, aber die nationalen Fahrpläne werden dagegen geschrieben – wer in der EU betreibt, hat es also mit dem Dokument zu tun, das die Sektoraufsicht gelesen hat.^[euroadmap]

Für den deutschsprachigen Raum kommt hinzu, dass Prüfer in der Praxis die BSI-Empfehlungslage heranziehen und nicht die NIST-Papiere, auch wenn beide auf dieselben Algorithmen hinauslaufen. Wer für ein Audit dokumentiert, sollte die jeweils gültige nationale Referenz direkt nachschlagen, statt sie aus internationalen Zusammenfassungen abzuleiten – und einkalkulieren, dass Hersteller-Firmware in jedem dieser Kalender die bindende Beschränkung ist. Steht ein Gerät in einem Fünfjahres-Austauschzyklus, ist die Beschaffung dieses Jahres eine Post-Quanten-Entscheidung, ob das im Vergabevorgang jemand ausspricht oder nicht.

Ein 90-Tage-Plan

Wer das Ganze auf einer Seite will, findet es hier. Die Prämisse: Der Schlüsselaustausch ist ein gelöstes Problem, das Sie lediglich ausrollen, und alles andere ist Vorbereitung.

Neunzig Tage sind für die ersten drei Phasen in den meisten Beständen realistisch, weil die Änderungen klein sind und das Risiko in der Bestandsaufnahme steckt, nicht in der Bearbeitung. Länger dauern immer dieselben zwei Dinge: Appliances, die sich nicht aktualisieren lassen, und Strecken, von denen niemand wusste. Beide finden sich in Woche eins, wenn Sie das Inventar ordentlich machen – was das Argument dafür ist, damit anzufangen.

Fünf Fehler, die Zeit kosten

Muster, die in realen Migrationen immer wieder auftauchen, grob nach Zeitverlust sortiert:

1. Fähigkeit statt Aushandlung prüfen. „Unsere Server unterstützen ML-KEM“ ist kein Befund. Ein Server kann es unterstützen und trotzdem den ganzen Tag klassische Handshakes für einen veralteten Client abschließen. Lesen Sie den ausgehandelten Algorithmus der Verbindung, nicht die Liste der unterstützten.
2. Die klassischen Verfahren entfernen. Hybride existieren gerade, damit Sie nicht wählen müssen. Post-Quanten-Gruppe nach vorn, X25519 dahinter – Schutz ohne Verfügbarkeitsvorfall.
3. Zertifikaten hinterherlaufen. Zeit, die 2026 in den Versuch fließt, ML-DSA-Zertifikate auszurollen, fehlt beim Austausch, der tatsächlich mitgeschnitten wird. Automatisieren Sie stattdessen die Ausstellung; das ist die Arbeit, die sich später auszahlt.
4. Am Rand aufhören. Der CDN-Handshake ist post-quantensicher, die Strecke zum Origin nicht. Das ist mit Abstand die häufigste Lücke, weil der externe Test besteht und sich beim internen Teilstück kein Nutzer beschwert.
5. Es als Einmalaktion behandeln. Ein neu gebautes Base Image, ein gepinntes Paket, eine zurückgerollte Konfiguration – und ein Host, der im März konform war, handelt im September klassisch aus. Legen Sie den Sweep auf einen Timer und alarmieren Sie, wenn die Zahl steigt.

Die Kurzfassung

Post-quantensicherer Schlüsselaustausch ist kein Zukunftsprojekt. Er ist eine Voreinstellung, die Sie vermutlich längst geerbt haben, und die ganze Arbeit besteht darin, die Verbindungen zu finden, die sie verpasst haben. Auf OpenSSH 10.x und OpenSSL 3.5+ aktualisieren, in beiden die hybride Gruppe nach vorn stellen, die Flotte auf das tatsächlich Ausgehandelte durchsuchen und die Ausnahmen mit Datum aufschreiben. Für die meisten Teams ist das eine Arbeitswoche, und es schließt den einzigen Angriff in diesem Feld, der heute läuft.

Und dann aufhören. Keine Zertifikate migrieren, keine Krypto-Agilitäts-Plattform kaufen, das Wort „Quanten“ nicht in ein Strategiepapier schreiben. Machen Sie die Zertifikatsausstellung automatisch und kurzlebig, halten Sie das Inventar aktuell und warten Sie auf das Ökosystem. Denn wenn Post-Quanten-Signaturen einsetzbar werden, sind die Organisationen, die das gut hinbekommen, nicht die mit dem frühesten Start – sondern die, die ein Zertifikat schon heute ohne Change-Fenster tauschen können.

Häufige Fragen

Muss ich etwas tun, wenn ich bereits OpenSSH 10 einsetze?

Verifizieren – und dann wahrscheinlich nicht. Der Standard ist mlkem768x25519-sha256, aber eine Härtungs-Baseline, ein CIS-abgeleitetes Template oder ein Konfigurationsmanagement-Modul kann eine eigene KexAlgorithms-Zeile geschrieben haben, die älter ist als ML-KEM und ihn stillschweigend ausschließt. Führen Sie ssh -v host exit 2>&1 | grep 'kex: algorithm' gegen einen echten Host aus und lesen Sie das ausgehandelte Ergebnis. Für eingehende Sitzungen zählt die Serverseite.

Bricht der post-quantensichere Schlüsselaustausch alte Clients?

Nicht, wenn Sie ihn als Präferenz statt als Einschränkung konfigurieren. Sowohl KexAlgorithms in SSH als auch die Gruppenliste in TLS sind geordnete Präferenzen: Hybrid nach vorn, curve25519-sha256 beziehungsweise X25519 dahinter – moderne Gegenstellen bekommen den Post-Quanten-Austausch, ältere fallen zurück. Kaputt geht es, wenn Sie die klassischen Einträge vollständig entfernen. Für eine geschlossene, vollständig kontrollierte Flotte ist das vertretbar, für alles Öffentliche nicht.

Reicht sntrup761x25519-sha512 oder muss ich auf ML-KEM wechseln?

Es ist echt quantenresistent und stoppt den Store-now-decrypt-later-Angriff heute, also genau die Eigenschaft, die Sie brauchen. Seine Schwäche ist die Standardisierung, nicht die Kryptografie: NTRU Prime wurde von NIST nicht ausgewählt, erfüllt also kein Compliance-Regime, das um FIPS 203 herum geschrieben ist, und die langfristige Implementierungsunterstützung ist unsicherer. Wer auf OpenSSH 9.0–9.8 sitzt und dieses Quartal nicht aktualisieren kann, ist geschützt. Planen Sie den Sprung auf 9.9+ trotzdem ein.

Warum kann ich nicht einfach jetzt Post-Quanten-Zertifikate ausrollen?

Weil ein Zertifikat nur nützt, wenn die prüfende Gegenstelle der signierenden Wurzel bereits vertraut – und in den Trust Stores der Browser liegt keine Post-Quanten-Wurzel. Sie können mit OpenSSL 3.5 ML-DSA-Schlüssel erzeugen und damit eine interne CA aufbauen, was für ein geschlossenes System ein sinnvolles Experiment ist. Für alles, was ein Browser anfasst, validiert die Kette nicht. Das ist ein Reihenfolgeproblem des Ökosystems, kein Konfigurationsproblem, und es löst sich über Jahre.

Wie prüfe ich, was mein TLS-Endpunkt tatsächlich aushandelt?

openssl s_client -connect host:443 -servername host -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null | grep 'Negotiated TLS1.3 group'. Für den Test selbst brauchen Sie einen OpenSSL-3.5+-Client; ein älterer Client erzeugt ein falsches Negativ, weil er die Gruppe nie angeboten hat. Führen Sie immer auch den Kontrolltest mit -groups X25519 aus, um zu bestätigen, dass Sie den Endpunkt gehärtet und nicht kaputtgemacht haben.

Muss ich mir um AES und SHA-256 Sorgen machen?

Nein. Grovers Algorithmus liefert gegen symmetrische Primitive eine quadratische Beschleunigung, was die Schlüssellänge effektiv halbiert: AES-256 behält eine Sicherheitsmarge von 128 Bit, SHA-256 bleibt ausreichend. AES-128 wird stärker diskutiert, ist aber nicht die praktische Sorge. Gebrochen werden durch Shors Algorithmus die asymmetrischen Verfahren – RSA, ECDH, ECDSA –, und genau die sind das gesamte Thema dieses Artikels.

Was ist mit VPNs, Datenbanken und Message Queues?

Dieselbe Regel, schwierigere Umsetzung. WireGuard hat in seinem Basisprotokoll keinen post-quantensicheren Schlüsselaustausch und stützt sich für eine hybride Anordnung auf seinen Pre-Shared-Key-Mechanismus. IPsec-Unterstützung hängt vollständig an der Firmware Ihres Herstellers. TLS bei Datenbanken und Brokern folgt meist dem TLS-Stack des jeweiligen Runtime und nicht dem System-OpenSSL – prüfen Sie also jedes einzeln, statt anzunehmen, eine systemweite Einstellung sei dort angekommen. Diese Strecken sind zugleich die wertvollsten Ziele, weil die Nutzlast genau jene langlebigen vertraulichen Daten sind, die der Sammelangriff einsammeln soll.

Ist das Compliance-Theater oder eine echte Bedrohung?

Die Bedrohung ist echt, aber zeitversetzt – und deshalb leicht in beide Richtungen falsch einzuschätzen. Niemand entschlüsselt heute Ihren Verkehr. Die Frage ist, ob heute mitgeschnittener Verkehr Mitte der 2030er noch schützenswert ist, und für Patientenakten, Finanzdaten, juristisches Material, Behördenkommunikation und langlebige Zugangsdaten lautet die Antwort eindeutig ja. Das Besondere an diesem Risiko ist, dass die Gegenmaßnahme fast nichts kostet – ein Versionssprung und eine Konfigurationszeile –, sodass die Kosten-Nutzen-Rechnung ohne Glauben an ein konkretes Eintrittsdatum aufgeht.

All das setzt voraus, dass das Basissystem stehen bleibt — das tut es nicht: das Upgrade von Ubuntu 24.04 auf 26.04 auf Servern beschreibt das Release-Upgrade, das sechs dieser Standardwerte unter Ihnen austauscht.

Quellen

Alle folgenden Quellen wurden beim Schreiben dieses Artikels gelesen. Release Notes der Projekte und Normungsdokumente werden gegenüber Sekundärberichterstattung bevorzugt zitiert; wo ein Dokument ein Entwurf und kein endgültiger Standard ist, wird es als solcher bezeichnet.

1. OpenSSH — Post-Quantum Cryptography (project page, FAQ and warning text)
2. OpenSSH 9.9 release notes (19 September 2024) — ML-KEM hybrid added; sntrup761x25519-sha512 gains its IANA name
3. OpenSSH 10.0 release notes (9 April 2025) — mlkem768x25519-sha256 becomes the default key agreement
4. OpenSSH 10.1 release notes (6 October 2025) — warning on non-post-quantum key agreement, WarnWeakCrypto
5. OpenSSH 8.5 release notes (3 March 2021) — sntrup761x25519-sha512@openssh.com replaces the older NTRU Prime hybrid, disabled by default
6. OpenSSH 10.3 release notes (2 April 2026)
7. OpenSSH 10.4 release notes (6 July 2026) — experimental mldsa44-ed25519 composite post-quantum signature scheme, not enabled by default
8. OpenSSH 10.5 release notes (11 August 2026) — current release at the time of writing
9. OpenSSH — full release notes index
10. ssh_config(5) — KexAlgorithms, WarnWeakCrypto, Match
11. sshd_config(5) — KexAlgorithms, HostKeyAlgorithms, Include
12. IETF draft-ietf-sshm-mlkem-hybrid-kex — hybrid ML-KEM key exchange for SSH
13. IETF draft-ietf-sshm-ntruprime-ssh — sntrup761x25519-sha512 for SSH (successor to the expired draft-josefsson document)
14. IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs — the composite signature scheme OpenSSH 10.4 implements
15. OpenSSL 3.5 series release notes — PQC support and hybrid groups preferred by default (3.5.0, 8 April 2025)
16. OpenSSL documentation — SSL_CTX_set1_groups_list(3), the TLS supported-groups list
17. OpenSSL documentation — SSL_CONF_cmd(3), the Groups command Apache passes through
18. nginx documentation — ssl_ecdh_curve in ngx_http_ssl_module
19. HAProxy configuration manual — ssl-default-bind-curves
20. IETF draft-ietf-tls-ecdhe-mlkem — hybrid ECDHE + ML-KEM groups for TLS 1.3
21. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
22. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
23. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
24. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)
25. NIST IR 8547 (Initial Public Draft, 12 November 2024) — Transition to Post-Quantum Cryptography Standards
26. European Commission / NIS Cooperation Group — Coordinated Implementation Roadmap for the Transition to PQC
27. Cloudflare — State of the post-quantum Internet in 2025
28. Cloudflare Radar — post-quantum encryption adoption (live figures)