Post-Quanten-Kryptografie: Muss ich mein Homelab jetzt umstellen?

Kurz gesagt: Umstellen im Sinne von „alles neu aufsetzen“: nein. Aktualisieren: ja, und zwar gezielt beim Schlüsselaustausch — dem Teil einer Verbindung, der heute mitgeschnitten und später mit einem Quantencomputer geknackt werden könnte. Bei SSH und HTTPS erledigt das im Wesentlichen ein aktuelles Software-Paket; prüfen kostet zwei Befehle. WireGuard hat keinen Post-Quanten-Schlüsselaustausch, bietet aber einen optionalen Pre-Shared Key als Zusatzschutz. Signaturen und Zertifikate sind nicht dringlich.

Ob und wann ein Quantencomputer heutige Verschlüsselung bricht, ist offen — den Hardware-Stand und die aktuellen Abschätzungen für RSA-2048 sortiert Was kann ein Quantencomputer wirklich?. Dieser Guide beantwortet die praktische Folgefrage: Was heißt das für die Dienste, die im eigenen Homelab laufen?

Warum „später“ schon heute zählt #

Verschlüsselte Verbindungen bestehen grob aus zwei Bausteinen:

• Schlüsselaustausch: Client und Server einigen sich über eine öffentliche Leitung auf einen gemeinsamen, geheimen Sitzungsschlüssel. Mit dem wird anschließend der eigentliche Verkehr verschlüsselt.
• Signatur (Authentifizierung): Der Server beweist, dass er wirklich der erwartete Server ist — über seinen Host-Key bei SSH oder sein Zertifikat bei HTTPS. Bei der SSH-Anmeldung per Schlüssel beweist umgekehrt der Nutzer seine Identität.

Beide beruhen heute meist auf Verfahren (RSA, elliptische Kurven), die ein ausreichend großer Quantencomputer brechen könnte. Der Unterschied liegt im Zeitpunkt, zu dem ein Angriff schadet.

NIST beschreibt das Risiko so: Manche Geheimnisse bleiben über viele Jahre wertvoll. Selbst wenn ein Angreifer eine Verschlüsselung heute nicht knacken kann, kann es sich für ihn lohnen, die verschlüsselten Daten aufzuzeichnen — in der Hoffnung, dass ein Quantencomputer sie später entschlüsseltBelegt. Im Englischen heißt das „harvest now, decrypt later“ oder „store now, decrypt later“. Trifft das den Schlüsselaustausch, fällt nachträglich der Sitzungsschlüssel und damit der gesamte mitgeschnittene Inhalt.

Bei Signaturen fehlt dieser Rückwirkungseffekt. Das OpenSSH-Projekt hält fest, dass eine künftig gebrochene Signatur kein Risiko für bereits übertragenen Verkehr bedeutet — es gibt kein Gegenstück zu „store now, decrypt later“. Bei Signaturen geht es darum, klassische Schlüssel auszumustern, bevor Quantencomputer tatsächlich verfügbar sindBelegt. Mit einer gebrochenen Signatur ließen sich nur künftige Verbindungen angreifen, etwa indem sich jemand als der eigene Server ausgibt — und dafür bräuchte es einen Quantencomputer, den es noch nicht gibt.

Daraus ergibt sich die Reihenfolge für jede Umstellung, auch im Homelab: zuerst Schlüsselaustausch, Signaturen später.

Die neuen Standards in einem Absatz #

Für den Schlüsselaustausch hat NIST im August 2024 mit FIPS 203 das Verfahren ML-KEM veröffentlicht, das auch gegen Angreifer mit Quantencomputer als sicher giltBelegt (KEM steht für Key Encapsulation Mechanism, das Verfahren hieß vorher Kyber). Für Signaturen kamen gleichzeitig ML-DSA (FIPS 204)Belegt und SLH-DSA (FIPS 205), abgeleitet von SPHINCS+Belegt. NIST rät, mit der Integration sofort zu beginnen, weil die vollständige Umstellung Zeit braucht, und bezeichnet SLH-DSA als Rückfallebene, falls sich ML-DSA als angreifbar erweisen sollteBelegt.

In der Praxis werden die neuen Verfahren fast überall hybrid eingesetzt: ein Post-Quanten-Verfahren kombiniert mit einem bewährten klassischen (meist X25519). Die Verbindung bleibt sicher, solange eines der beiden hält. Die Namen verraten das: mlkem768x25519-sha256 bei SSH, X25519MLKEM768 bei TLS.

SSH: meistens schon erledigt — prüfen statt raten #

Seit wann OpenSSH welche hybriden Verfahren standardmäßig nutzt, steht im Quantencomputer-Artikel oben. Für den Homelab-Check zählt: Ein Post-Quanten-Schlüsselaustausch kommt nur zustande, wenn beide Seiten ihn können und keine Konfiguration ihn abschaltet. Geprüft wird deshalb in drei Schritten.

1. Was kann mein Client?

ssh -V
ssh -Q kex

ssh -V zeigt die Version, ssh -Q kex listet alle Schlüsselaustausch-Verfahren, die der Client beherrscht. Enthält die Liste mlkem768x25519-sha256 und/oder sntrup761x25519-sha512, ist der Client bereit.

2. Was wird tatsächlich ausgehandelt?

ssh -v nutzer@server.example.lan exit 2>&1 | grep "kex: algorithm"

Die Debug-Ausgabe (-v) nennt das Verfahren, auf das sich beide Seiten geeinigt haben. Bei der Arbeit an dieser Artikelserie lieferte ein Client mit OpenSSH 9.9p2 gegen einen öffentlichen Server zum Beispiel:

debug1: kex: algorithm: sntrup761x25519-sha512

Das ist hybrid und damit post-quanten-gesichert. Steht dort dagegen curve25519-sha256 oder ein ecdh-sha2-…/diffie-hellman-…-Verfahren, ist eine Seite zu alt oder falsch konfiguriert.

Ab OpenSSH 10.1 muss man nicht einmal suchen: Der Client warnt dann selbst mit „connection is not using a post-quantum key exchange algorithm“. Die Warnung lässt sich über die Option WarnWeakCrypto in ssh_config abschaltenBelegt — sinnvoller ist, den Server zu aktualisieren.

3. Was bietet der Server an?

Auf dem Server selbst (hier server.example.lan):

ssh -V
sudo sshd -T | grep -i kexalgorithms

ssh -V zeigt die Version des OpenSSH-Pakets, das auf dem Server installiert ist. sshd -T ist laut Manpage ein erweiterter Testmodus: Er prüft die Konfigurationsdatei, gibt die tatsächlich wirksame Konfiguration aus und beendet sichBelegt — der laufende Dienst wird dabei nicht angefasst. Die Ausgabe zeigt die Zeile kexalgorithms mit allen angebotenen Verfahren, also auch das, was Distribution oder eigene Drop-in-Dateien daraus gemacht haben.

Fehlen dort die hybriden Verfahren, gibt es zwei Ursachen:

• Zu alte Version. Das OpenSSH-Projekt empfiehlt Servern mindestens Version 9.0 (für sntrup761x25519-sha512) beziehungsweise 9.9 oder neuer (für mlkem768x25519-sha256)Belegt. Typische Kandidaten im Homelab: ältere LTS-Distributionen, NAS-Systeme, Router, Switches und andere Embedded-Geräte mit eigener SSH-Implementierung. Dort hilft nur ein Firmware- oder Systemupdate.
• Harte Konfiguration. Wer früher nach einer Härtungsanleitung eine feste KexAlgorithms-Liste eingetragen hat, sperrt neue Verfahren unbemerkt aus. Laut sshd_config-Manpage steht mlkem768x25519-sha256 in aktuellen Versionen ganz vorn in der Standardliste; mit einem - vor der Liste lassen sich einzelne Verfahren aus den Standards entfernen, mit + welche anhängen und mit ^ welche nach vorn stellenBelegt. Statt die komplette Liste zu überschreiben, ist es daher robuster, nur Unerwünschtes mit - auszuschließen — dann kommen neue Standardverfahren bei Updates automatisch dazu.

Vor jeder Änderung an sshd_config gilt: Konfiguration mit sudo sshd -t prüfen und eine bestehende SSH-Sitzung offen lassen, bis eine zweite Anmeldung funktioniert hat. Wer sich aussperrt, braucht sonst Konsole oder physischen Zugang.

Und die SSH-Schlüssel? Die Datei ~/.ssh/id_ed25519 ist ein Signaturschlüssel. Nach der Logik oben besteht kein Grund, sie wegen Quantencomputern heute auszutauschen.

HTTPS: Browser sind weiter als die meisten Homelab-Dienste #

Beim Web kommt die Umstellung von der Browserseite. Google hat angekündigt, dass Chrome ab Version 131 für den hybriden Schlüsselaustausch vom Vorab-Kyber auf das standardisierte ML-KEM wechselt (hybrid mit X25519) und diese Variante direkt im ersten Verbindungsaufbau anbietetHerstellerangabe. Ob sie genutzt wird, entscheidet aber der Server — im Homelab also meist der Reverse Proxy vor den Diensten.

OpenSSL-basierte Server wie nginx. OpenSSL 3.5 unterstützt ML-KEM, ML-DSA und SLH-DSA; die Standard-Keyshares für TLS bieten seit dieser Version X25519MLKEM768 und X25519 an, und die Standardliste der Gruppen bevorzugt hybride Post-Quanten-VerfahrenBelegt. Die OpenSSL-Doku nennt als Preis deutlich größere Handshake-Nachrichten bei vergleichbarer CPU-Last wie das klassische VerfahrenBelegt. nginx verwendet mit der Standardeinstellung ssl_ecdh_curve auto die in OpenSSL eingebaute ListeBelegt. Daraus folgt: Läuft nginx mit OpenSSL 3.5 oder neuer und steht ssl_ecdh_curve nicht auf einer festen, alten Liste, sollte X25519MLKEM768 ohne weiteres Zutun angeboten werden. Bei älteren OpenSSL-Versionen fehlt das Verfahren — maßgeblich ist die Version, gegen die das Paket bzw. das Container-Image gebaut ist, nicht die des Hosts.

Go-basierte Server wie Caddy. Seit Go 1.24 ist X25519MLKEM768 in der TLS-Bibliothek von Go standardmäßig aktiv, solange eine Anwendung keine eigene Kurvenliste setztBelegt. Caddy unterstützt die Gruppe seit Version 2.10.0 standardmäßigBelegt. Für andere Go-Programme gilt die Regel sinngemäß: Es kommt auf die Go-Version an, mit der sie gebaut wurden, und darauf, ob sie die Kurven selbst festlegen.

Prüfen lässt sich das von einem Rechner mit OpenSSL 3.5 oder neuer, indem man nur die hybride Gruppe anbietet:

openssl version
openssl s_client -connect server.example.lan:443 -groups X25519MLKEM768 -brief </dev/null

-groups legt fest, welche Schlüsselaustausch-Gruppen der Client anbietet; OpenSSL 3.5 kennt dafür unter anderem die hybride Gruppe X25519MLKEM768Belegt. Kommt die Verbindung zustande, beherrscht der Server das Verfahren; bricht der Handshake ab, nicht. Der Befehl baut nur eine Verbindung auf und ändert nichts am Server.

Wie wichtig das im Homelab ist, hängt vom Weg ab: Dienste, die übers Internet erreichbar sind, laufen durch fremde Netze, in denen mitgeschnitten werden kann. Für ein Dashboard, das nur im eigenen LAN hängt, ist das Mitschnitt-Risiko deutlich kleiner — ein Update schadet trotzdem nicht.

WireGuard: kein Post-Quanten-Handshake, aber ein Zusatzschloss #

WireGuard handelt Schlüssel über Curve25519 aus, ein klassisches Verfahren. Einen Post-Quanten-Schlüsselaustausch hat das Protokoll nicht. Die Protokollbeschreibung nennt aber eine Option: Wer eine zusätzliche Schicht symmetrischer Kryptografie braucht — ausdrücklich etwa für Post-Quanten-Resistenz —, kann einen optionalen Pre-Shared Key verwenden, der in die Public-Key-Kryptografie eingemischt wirdBelegt. Ohne diesen Schlüssel setzt WireGuard an der Stelle einen Nullwert ein.

Die Idee dahinter: Der Sitzungsschlüssel hängt dann zusätzlich an einem Geheimnis, das nie über den Curve25519-Handshake läuft. Ein Angreifer, der später den Curve25519-Teil bricht, hätte ohne den Pre-Shared Key noch nicht den Sitzungsschlüssel.

wg genpsk erzeugt einen zufälligen Pre-Shared Key; in der Konfiguration steht er als optionales Feld PresharedKey im jeweiligen [Peer]-AbschnittBelegt:

# erzeugt einen Schlüssel und schreibt ihn in eine Datei nur für root
umask 077
wg genpsk > peer-laptop.psk

[Peer]
PublicKey = <PUBLIC_KEY_DES_PEERS>
PresharedKey = <INHALT_VON_peer-laptop.psk>
AllowedIPs = 10.0.0.2/32

Drei Dinge dazu:

• Der Pre-Shared Key ist ein Geheimnis wie ein privater Schlüssel. Er muss auf beiden Seiten eines Peer-Paars identisch eingetragen sein, und pro Peer-Paar sollte ein eigener Schlüssel verwendet werden.
• Er schützt nur, wenn er selbst nicht über einen angreifbaren Weg übertragen wird. Per Chat oder unverschlüsselter Mail verschickt, ist der Zusatznutzen dahin; sinnvoll ist ein Weg, der ohnehin schon post-quanten-gesichert ist (etwa eine SSH-Sitzung mit hybridem Schlüsselaustausch) oder die direkte Übertragung vor Ort.
• Ändern sich die Schlüssel eines Tunnels, fällt er kurz aus, bis beide Seiten die neue Konfiguration geladen haben. Also außerhalb der Zeit umstellen, in der der Tunnel gebraucht wird, und einen zweiten Zugang bereithalten, falls der Tunnel der einzige Weg ins Netz ist.

Wie viel der Pre-Shared Key in der Praxis bringt, hängt davon ab, wie sorgfältig er erzeugt, verteilt und gewechselt wird — ein vollwertiger Post-Quanten-Schlüsselaustausch im Protokoll ist er nicht.Evidenz: Theorie Andere VPN-Protokolle wie IPsec oder OpenVPN klammert dieser Guide bewusst aus; dort hängt der Stand stark von Implementierung und Version ab.

Was ist dringlich, was kann warten? #

Wie groß das Mitschnitt-Risiko für ein einzelnes Homelab tatsächlich ist, lässt sich nicht beziffern.Evidenz: Spekulation Realistisch betrachtet dürfte sich kaum jemand für den SSH-Verkehr eines privaten Homeservers interessieren. Die Abwägung ist trotzdem einfach: Der größte Teil der Umstellung ist ein Update, das man aus anderen Gründen ohnehin einspielen sollte.

Reality Check (Stand September 2026): Belegt ist, dass NIST Post-Quanten-Standards für Schlüsselaustausch und Signaturen veröffentlicht hat und dass OpenSSH, OpenSSL 3.5, Go 1.24 und Caddy 2.10 hybride Verfahren standardmäßig anbieten; Chromes Umstellung ist eine Herstellerangabe. Kein heute existierender Quantencomputer kann diese Verbindungen angreifen — geschützt wird gegen einen künftigen Angreifer, dessen Zeitpunkt offen ist. Wie weit Quantenhardware davon entfernt ist, ordnet Quantencomputer oder GPU? aus der Hardware-Perspektive ein; den größeren Rahmen neuer Rechnerarchitekturen zeigt Was kommt nach CPU und GPU?.

Was heißt das fürs eigene Homelab? Die Checkliste #

• ssh -Q kex auf den Rechnern, von denen aus administriert wird: mlkem768x25519-sha256 oder sntrup761x25519-sha512 vorhanden?
• Für jeden SSH-Server einmal ssh -v … 2>&1 | grep "kex: algorithm": wird ein hybrides Verfahren ausgehandelt?
• Auf Servern ohne hybrides Verfahren: ssh -V und sudo sshd -T | grep -i kexalgorithms — Update fällig oder eine alte, harte KexAlgorithms-Liste im Weg?
• Geräte mit eigener SSH-Implementierung (NAS, Router, Switch) auf Firmware-Updates prüfen.
• Reverse Proxy: OpenSSL-Version bzw. Caddy-/Go-Version prüfen, keine feste alte Kurvenliste; Test mit openssl s_client … -groups X25519MLKEM768.
• Übers Internet erreichbare Dienste zuerst, reine LAN-Dienste später.
• WireGuard: bei Tunneln über fremde Netze einen Pre-Shared Key pro Peer erwägen, sicher verteilen.
• SSH-Schlüssel und Zertifikate: bewusst nichts tun — hier gibt es keinen Zeitdruck.

Unterm Strich: Ein Homelab muss für Quantencomputer nicht umgebaut werden. Wer seine Systeme ohnehin aktuell hält, ist beim Schlüsselaustausch schon weit gekommen — die Befehle oben zeigen in ein paar Minuten, wo noch eine Lücke ist.