OpenSSH und Post-Quanten-Kryptografie
(openssh.com)- OpenSSH unterstützt Post-Quanten-Verschlüsselungsalgorithmen, die gegen Angriffe durch Quantencomputer resistent sind
- Seit Version 9.0 ist standardmäßig der sntrup761x25519-sha512-Algorithmus aktiv, und ab Version 10.0 wird mlkem768x25519-sha256 als Standard-Verbindungsmodus verwendet
- Ab Version 10.1 wird bei Nichtnutzung eines post-quantenfähigen Schlüsselaustauschs eine Warnmeldung angezeigt
- Die meisten bisherigen Signaturalgorithmen (RSA, ECDSA usw.) werden ebenfalls nachträglich unterstützt
- Um den bestehenden Datenverkehr sicher zu schützen, müssen sowohl Server als auch Client Post-Quanten-Algorithmen einsetzen
Einführung von Post-Quanten-Kryptografie in OpenSSH
OpenSSH unterstützt mehrere Schlüsselvereinbarungsalgorithmen, die auch gegen Angriffe durch Quantencomputer sicher sind
Es wird empfohlen, diese Algorithmen für alle SSH-Verbindungen zu verwenden.
OpenSSH 9.0 (2022) stellt standardmäßig über sntrup761x25519-sha512 den Post-Quanten-Schlüsselaustausch (KexAlgorithms) bereit, und ab Version 9.9 wurde mlkem768x25519-sha256 ergänzt
Seit OpenSSH 10.0 ist mlkem768x25519-sha256 als Standard-Verschlüsselungsverfahren festgelegt
Um die Einführung von Post-Quanten-Algorithmen zu fördern, zeigt OpenSSH ab Version 10.1 eine Warnung an, wenn kein quantenresistenter Schlüsselaustausch verwendet wird
** WARNING: connection is not using a post-quantum kex exchange algorithm. **
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded. See https://openssh.com/pq.html
Diese Warnung wird standardmäßig angezeigt, kann jedoch über die Option WarnWeakCrypto in ssh_config(5) deaktiviert werden
Hintergrund
Ein Quantencomputer ist ein Gerät, das Informationen als Quantenzustände kodiert und darauf berechnet
Er kann bestimmte mathematische Probleme lösen, die klassische Rechner nicht leisten können
Die Grundannahmen vieler kryptografischer Algorithmen basieren auf Problemen, die von Quantencomputern leicht gelöst werden könnten Wenn ein ausreichend leistungsfähiger Quantencomputer (auf einem kryptographisch relevanten Niveau) auftaucht, besteht das Risiko, dass diese Kryptografie gebrochen wird Besonders betroffen sind Algorithmen, die für Schlüsselaustausch und digitale Signaturen verwendet werden
Solche Quantencomputer sind noch nicht realisiert, aber Experten erwarten ihr Auftreten innerhalb von 5 bis 20 Jahren oder Mitte der 2030er Jahre
Die Datenschutzgarantie einer SSH-Verbindung hängt von der Schlüsselaustausch-Verschlüsselung ab
Wenn ein Angreifer den Schlüsselaustauschalgorithmus bricht, kann er den gesamten Sitzungsinhalt entschlüsseln
Daneben ist ein Angriff möglich, bei dem ein Angreifer den Sitzungstext speichert und ihn später mit einem Quantencomputer entschlüsselt: „store now, decrypt later“
OpenSSH stärkt dazu die Unterstützung für Post-Quanten-Kryptografie
FAQ
Q: Ich habe von ssh eine Warnung erhalten – was soll ich tun?
- OpenSSH warnt ab Version 10.1, wenn eine nicht quantensichere Verschlüsselung verwendet wird
- Das bedeutet, dass der verbundene Server keine Post-Quanten-Schlüsselaustausch-Algorithmen bereitstellt (mlkem768x25519-sha256, sntrup761x25519-sha512)
- Die beste Maßnahme ist ein Update des Servers auf OpenSSH 9.0 oder höher (für Letzteres auf 9.9 oder höher), sowie die Überprüfung, dass die betreffenden Algorithmen in KexAlgorithms nicht deaktiviert sind
- Falls ein Server-Update nicht möglich ist oder das Risiko bewusst in Kauf genommen wird, kann die Warnung auch über die Option WarnWeakCrypto in ssh_config(5) nur ausgeblendet werden
- Falls erforderlich, sollte das nur für bestimmte Hosts gelten, wie im folgenden Beispiel:
Match host unsafe.example.com WarnWeakCrypto no
Q: Warum vorbeugen, obwohl es noch keine Quantencomputer gibt?
- Wegen des zuvor erwähnten Angriffs "store now, decrypt later"
- Auch heute gesendeter Traffic kann später entschlüsselt werden, daher wird bereits jetzt eine post-quanten-sichere Verbindung empfohlen
Q: Wenn auch Signaturalgorithmen gefährdet sind, warum ist das kein sofortiges Problem?
- Auch die meisten Signaturalgorithmen (RSA, ECDSA usw.) können durch einen Quantencomputer ausgeschaltet werden
- In diesem Fall werden jedoch keine Datenpakete gespeichert und später entschlüsselt
- Bei Signaturalgorithmen liegt das Eilbedürftige eher darin, bestehende Signaturschlüssel aus dem Verkehr zu ziehen, sobald ein Quantencomputer näher rückt
- OpenSSH plant, künftig auch post-quantenfähige Signaturalgorithmen zu unterstützen
Q: Warum ist das wichtig, wenn ich denke, dass Quantencomputer unmöglich sind?
- Manche halten es für unmöglich, doch die derzeitigen technischen Hürden sind vor allem Ingenieursprobleme, nicht Grundsatzfragen der Physik
- Wenn Quantencomputer möglich sind, schützt diese Maßnahme heute potenziell riesige Nutzer*innendaten
- Selbst wenn sich im Nachhinein zeigt, dass diese Vorbereitung nicht nötig war, ist sie nur eine Migration zu kryptografisch stärkerer Technik
Q: Sind Post-Quanten-Algorithmen vielleicht ebenfalls angreifbar?
- Auch OpenSSH geht hier vorsichtig vor
- Obwohl nur Algorithmen ausgewählt wurden, die in den letzten Jahren intensiv überprüft wurden, besteht weiterhin die Möglichkeit neuer Angriffsmethoden
- Zur Kompensation werden nur Algorithmen mit großzügiger Sicherheitsmarge eingesetzt, sodass auch bei unerwarteter Schwächung eine praxisnahe Sicherheitsstufe wahrscheinlicher bleibt
- Zudem sind alle Post-Quanten-Algorithmen von OpenSSH als „hybrid“ ausgelegt
- Beispiel: mlkem768x25519-sha256 kombiniert ML-KEM (Post-Quantum) mit dem klassischen Algorithmus ECDH/x25519
- So bleibt selbst wenn der Post-Quanten-Teil später kompromittiert wird, mindestens das bisherige Sicherheitsniveau erhalten
1 Kommentare
Hacker News Kommentar
Am unteren Teil der Seite sind wichtige Inhalte versteckt. Alle auf OpenSSH angewendeten Post-Quantum-Algorithmen nutzen einen "hybriden" Ansatz, der gleichzeitig eine post-quanten Schlüsselaustauschmethode (z. B. ML-KEM) und eine klassische Methode (x25519) kombiniert. Dadurch kann selbst dann zumindest das bisherige Sicherheitsniveau gehalten werden, wenn ein Post-Quantum-Algorithmus in der Zukunft vollständig gebrochen wird. Der entscheidende Punkt ist, dass es mit diesem hybriden Ansatz gegenüber dem bisherigen Stand keinen Sicherheitsverlust gibt.
Der hybride Ansatz hat den Vorteil, dass selbst wenn eine Seite kompromittiert wird, das andere Verfahren Redundanz bietet. Andererseits vervielfacht er jedoch das Risiko für Implementierungsfehler und Seitenkanallücken eher deutlich. In der Praxis ist eine Quantencomputer-Bedrohung aktuell noch nicht real, aber solche Fehler und Schwachstellen sind ein sofortiges, reales Thema. Über die letzten zehn Jahre wurden jedoch immense Sicherheitsforschung und Verifikation betrieben, sodass man diesen Trade-off als vertretbar ansieht.
Die gesamte Industrie bewegt sich überwiegend in hybriden PQC-Klassik-Strukturen. Bis ein echter Quantencomputer auftaucht, der RSA, ECC oder DH wirklich bricht, wirkt ein konservativer Ansatz mit zwei parallel gesetzten Schlössern aktuell als die sicherste Wahl. Die offizielle FAQ zu den CNSA-2.0-Algorithmen der NSA (Link) sagt dagegen, dass nur Post-Quantum-Verfahren übernommen werden sollen und ein hybrider Ansatz nicht nötig sei.
Vor dem kürzlich veröffentlichten, teils polemischen, aber interessanten Paper (Link) frage ich mich, ob die aktuelle Einführungsgeschwindigkeit von Post-Quantum-Krypto wirklich nötig ist. Nach meinem Kenntnisstand sind Post-Quantum-Schlüsselmaterialien im Vergleich zu früher deutlich größer, was sowohl Netzwerkverkehr als auch CPU-Last deutlich erhöht.
Diese Ausarbeitung bezieht sich nur auf den Einsatz von PQC beim Schlüsselaustausch in SSH-Verbindungen; der Overhead bleibt daher ziemlich gering. Und wie auch die FAQ sagt, ist die Antwort auf die Frage „Warum jetzt vorbereiten, wenn es noch keinen Quantencomputer gibt?“: der Verkehr, der heute übertragen wird, könnte später entschlüsselt werden (Attacke „store now, decrypt later"). Auch wenn manche bezweifeln, dass Quantencomputer überhaupt realisierbar sind, ist das Hauptproblem eher ein Engineering-Thema als ein physikalisches. Wenn Quantencomputer tatsächlich Realität werden, könnte man eine riesige Menge an Benutzerdaten kompromittieren. Die Arbeit ist humorvoll, aber nicht bloß als Anlass für Spott; sie ist einen einmaligen Durchgang wert, ohne sie übermäßig zynisch zu lesen.
Sie ist zwar lustig, aber nicht nur lächerlich. Tatsächlich wird auch echter Fortschritt erzielt. Ich empfehle den Vortrag von Sam Jacques auf PQCrypto 2025 (Link). In den letzten zehn Jahren sind die Kosten für quanteninspirierte Faktorisierung um den Faktor 1000 gesunken, und die Hardware-Fehlerraten wurden massiv reduziert (Link1, Link2, Link3, Link4). Wenn Sie die Quantenentwicklung beobachten möchten, achten Sie auf die graduelle Verbesserung der Fehlertoleranz. Das Rauschen ist die große Hürde, und wenn die Qualitätsprobleme auf beiden Seiten gelöst sind, ist mit echter Fortschritt zu rechnen.
Diese Arbeit wirkt wie ein Scherz. Würde man sie ernsthaft kritisieren, wäre das vergleichbar mit der Beschwerde aus dem Jahr 1951, dass ein Transistor Pi nicht berechnen kann. Die Notwendigkeit von PQC hängt von zwei Fragen ab: 1) Ob Sie glauben, dass Ihr Leben ohne Quantencomputer auskommt, 2) Wie hoch Sie die Sensitivität der Daten bewerten, die Sie anvertrauen. Wenn beide Punkte keine Rolle spielen, könnte PQC Zeitverschwendung sein. Wenn man jedoch ein Kryptosystem betreibt, hat man meiner Meinung nach keine Befugnis, den Wert der Benutzerdaten zu ignorieren.
Der Großteil der aktuellen Diskussion dreht sich um den Schlüsselaustausch. Dieser findet selten statt, und der Overhead ist meist nicht problematisch. Zusammengefasst: 1) PQ-Algorithmen (Signatur, Schlüsselaustausch) haben deutlich größere Schlüssel, sind jedoch bei der Berechnung schneller oder vergleichbar. 2) In den meisten Protokollen wie TLS oder SSH findet der Schlüsselaustausch nur beim Verbindungsaufbau statt, daher sind größere Schlüsselgrößen dort meist kein großes Problem. Es kann jedoch zu Kompatibilitätsproblemen kommen, etwa durch Überschreitung der TCP-MTU. In Protokollen wie Signal und MLS, die sehr häufig Schlüssel austauschen, wird PQ nur gelegentlich eingesetzt (Hinweis). 3) Bei TLS ist die Signaturnachrichten-Größe eher das Problem, weil Zertifikatsketten viele Signaturen enthalten. Deshalb ist die Einführungsmöglichkeit von PQ-Signaturen in TLS mit größerer Unsicherheit behaftet (Hinweis)
Abseits der öffentlichen Informationen ist ein Vertrauensfaktor, dass unsere Nachrichtendienste den Einsatz von PQ für Systeme mit über 20 Jahren Geheimhaltungspflicht empfehlen. Zum Abgleich: Die niederländischen Dienste nannten 2014 den Zeitraum 2030 bis 2040; 2021 wurde gesagt, dass bis 2030 zwar geringe Wahrscheinlichkeit, aber kein Ausschlussgrund, ein Auftreten zu haben sei. 2025 gaben 18 Länder in einer gemeinsamen Stellungnahme aus, dass bis 2030 auf „store now, decrypt later“-Angriffe vorzusorgen sei (Dokument1, Dokument2, Gemeinsame Erklärung)
Die macOS-App Secretive speichert SSH-Schlüssel im Secure Enclave. Aufgrund der unterstützten Algorithmen nutzt sie ecdsa-sha2-nistp256, was darauf hindeutet, dass PQ-Algorithmen dort wahrscheinlich nicht unterstützt werden. Könnte man etwa mlkem768×ecdsa-sha2-nistp256 hybridisieren, sodass nur der ECDSA-Teil in SE verarbeitet wird (Secretive GitHub)
Ich denke, dass das Tool ssh-audit (Link) einen zusätzlichen Check für theoretische (PQC-Hybrid-)Algorithmen ergänzen sollte. Es scheint weiterhin eine „A“-Bewertung zu liefern, selbst wenn nur ein einzelner Algorithmus fix gesetzt ist. Im Moment setze ich nur ChaCha ein.
Mich interessiert, ob es für OpenSSH FIPS-140-3-konforme PQC-Hybrid-Algorithmen gibt.
Die frühe Vorbereitung ist sinnvoll. Je einfacher ein Schlüsseltausch, desto eher. Ich frage mich, welche Option stärker ist; ist nicht 512 stärker?
Die beiden Algorithmen sind komplett verschieden. mlkem768x25519-sha256 kombiniert ML-KEM-PQ-Schlüsselaustausch mit klassischem ECDH/x25519. So ist selbst bei einer Kompromittierung eines Teils mindestens das klassische Sicherheitsniveau erhalten. Und die 256-Version (mlkem768) kam tatsächlich später als die 512-Version (sntrup761); OpenSSH unterstützte sntrup761x25519-sha512 ab 9.0 und mlkem768x25519-sha256 ab 9.9.
Die Frage nach 256- vs. 512-Bit- Größen ist derzeit absolut nicht dringlich. Einen 128-Bit-Raum gibt es nicht einmal mit ausreichender Energie zur vollständigen Durchsuchung, und solche Rechner existieren nicht. Das ist nicht der richtige Zeitpunkt, sich Sorgen zu machen.
mlkem ist heute der vernünftige Default. Die Branche zieht sich in diese Richtung zusammen.
Ich überlege, meine terminalbasierte Microblogging-/Chat-App auf Post-Quantum-Sicherheit umzustellen. Das Paul-Durov-Interview habe ich mehrfach gesehen und seine Erfahrungen gehört, was diese Überlegung verstärkt hat.
Was ist besser: sntrup761x25519-sha512 oder mlkem768x25519-sha256?
MLKEM768 bietet bessere Performance und kleinere Schlüssel. SNTRUP761 hat stärkere Sicherheitsannahmen und ist robuster gegen potenzielle kryptographische Angriffe.
NTRU Prime (sntrup) ist aus historischen Gründen eingeführt worden (mlkem war damals nicht verfügbar). Beides ist nutzbar; sntrup wirkt wie eine frühere Defaults-Einstellung, ähnlich wie CAST einmal in GPG als Standard.
Mich interessiert, wann auch PQ-Zertifikate (Host-/Nutzer-Authentifizierungsschlüssel) angeboten werden.
Es ist sinnvoll, sich hier frühzeitig zu engagieren. Auch wenn in Zukunft Alternativen mit stärkerer Sicherheit erscheinen, ist die Arbeit nicht sinnlos, solange sie nicht schlechter ist als der aktuelle Zustand.