Harvest-now-decrypt-later stellt diese Annahme infrage. Von aussen betrachtet ist ein VPN-Tunnel nur ein Strom verschlüsselter Pakete, und wer auf dem Übertragungsweg sitzt, kann ihn schon heute aufzeichnen. Sobald ein kryptografisch relevanter Quantencomputer den Schlüsselaustausch des Tunnels bricht, liegt alles darin offen, auch jedes interne Protokoll, das sich für seine Vertraulichkeit auf den Tunnel verlassen hat. Da ein einziger Schlüsselaustausch den gesamten Datenverkehr zwischen zwei Netzwerken absichert, ist ein VPN ein besonders lohnendes Ziel für alle, die heute mitschneiden und später entschlüsseln.

Im dritten Teil dieser Serie nehmen wir uns WireGuard vor, das sich als moderner Standard durchgesetzt hat, und messen, was es kostet, es quantensicher zu machen.

Anders als TLS und SSH ist WireGuard nicht kryptoagil, und das mit Absicht. Es gibt keine Aushandlung von Algorithmen, sondern einen festen Satz an Primitiven. Das hält den Handshake schlank, heisst aber auch: ML-KEM lässt sich nicht einbauen, ohne das Protokoll selbst zu ändern. Ein quantensicheres WireGuard muss deshalb durch die einzige Tür, die seine Entwickler offen gelassen haben, einen optionalen Pre-Shared Key:

Dieser symmetrische 32-Byte-Schlüssel fliesst in jeden Handshake ein, und das WireGuard-Whitepaper nennt ihn ausdrücklich als Schutz vor künftigen Quantenangriffen. Wer X25519 bricht, kommt ohne ihn trotzdem nicht an die Sitzungsschlüssel. Und gelangt der Pre-Shared Key in falsche Hände, ist die Verbindung immer noch so sicher wie ein normales WireGuard. Das ist dasselbe hybride Prinzip wie bei TLS und SSH.

Der Haken: Ein statischer Schlüssel in einer Konfigurationsdatei muss von Hand verteilt und erneuert werden und ändert sich nie von selbst. Besser ist es, den Schlüssel regelmässig automatisch neu auszuhandeln, über einen Post-Quantum-Schlüsselaustausch, der parallel zu WireGuard läuft.

Rosenpass kombiniert zwei Post-Quantum-Verfahren. Jeder Peer hat einen statischen Classic-McEliece-Schlüssel, und jeder Handshake enthält zusätzlich einen ML-KEM-Austausch mit einem frisch erzeugten, kurzlebigen Schlüssel. McEliece und ML-KEM fliessen beide in den endgültigen Schlüssel ein.

Rosenpass nutzt McEliece für die statischen Schlüssel, weil die Ciphertexts klein sind: 188 Bytes gegenüber 768 bei ML-KEM. Die öffentlichen Schlüssel sind dafür riesig, rund 512 KB. Wie bei WireGuard werden sie aber nur einmal vorab ausgetauscht und gehen während eines Handshakes nie über das Netzwerk.

Im September 2026 hat das deutsche BSI allerdings von Classic McEliece abgeraten, zumindest für Neuentwicklungen, nach neuen Angriffen, die in der Praxis noch nicht durchführbar sind. Da Rosenpass zusätzlich ML-KEM nutzt, bleiben aufgezeichnete Verbindungen geschützt. Betroffen wäre nur die Authentifizierung.

Auch andere Produkte setzen auf McEliece und ML-KEM: Mullvad VPN leitet damit seinen WireGuard-Pre-Shared-Key ab, und NetBird bindet Rosenpass direkt ein.

Anders als in unseren bisherigen Beiträgen gibt es diesmal nur zwei mögliche Konfigurationen: auf beiden Seiten WireGuard allein oder auf beiden Seiten WireGuard mit Rosenpass. Da Rosenpass ein eigenes Protokoll ist, müssen beide Seiten gleichzeitig umstellen.

Mit Rosenpass wächst der Handshake um 2.6 KB, von 324 B auf 3.0 KB. Der Handshake von WireGuard selbst bleibt bei 324 B. Der gesamte Mehraufwand geht also auf Rosenpass zurück, vor allem auf ML-KEM.

Rosenpass braucht zwei Round Trips, das kostet 49 ms auf einem guten Netzwerk und 70 ms auf schlechtem Wi-Fi. Der Handshake von WireGuard selbst bleibt unverändert. Auf Wi-Fi dauert er einfach länger, weil das Netzwerk langsamer ist.

In unserem Lab laufen die beiden Handshakes nacheinander ab. In der Praxis ist das nicht nötig: WireGuard weiss nichts von Rosenpass und nimmt bei seinem nächsten Handshake einfach den zuletzt erhaltenen Schlüssel.

Bei einem genutzten Tunnel fällt das kaum ins Gewicht. Auf einen Arbeitsnachmittag über unser eigenes WireGuard-VPN hochgerechnet, hätte Rosenpass den Datenverkehr um 0.13% erhöht, gegenüber 0.02% für die Handshakes von WireGuard selbst.

OpenVPN handelt seine Schlüssel in einem TLS-Handshake aus. Wer OpenVPN quantensicher machen will, muss also TLS quantensicher machen. Ab OpenSSL 3.5 kann es denselben hybriden Schlüsselaustausch X25519MLKEM768 aushandeln wie Browser. Die Kosten kennen wir aus unserem TLS-Beitrag: ein paar Kilobytes pro Handshake und keine spürbare Verzögerung.

Bei der Authentifizierung sieht es anders aus. OpenVPN authentifiziert Server und Client in der Regel mit X.509-Zertifikaten, und mit ML-DSA werden Zertifikate und Signaturen um ein Mehrfaches grösser.

Auch IPsec setzt beim Schlüsselaustausch auf das hybride Verfahren. Die Peers können nach dem klassischen Austausch weitere Schlüsselaustausche anhängen, und die IETF standardisiert gerade ML-KEM als Post-Quantum-Variante. Zur Authentifizierung nutzt IPsec entweder Zertifikate, mit derselben Grössenfrage bei ML-DSA wie OpenVPN, oder Pre-Shared Keys, deren sicherer Austausch dann beim Administrator liegt.

Sein grösster Nachteil: Rosenpass ruht nie. Es erneuert den Schlüssel alle zwei Minuten, auch wenn der Tunnel gar nicht genutzt wird. Ein «Lazy Mode», der wie WireGuard nur bei laufendem Traffic erneuert, würde den Grossteil dieser Kosten sparen. Ob das Rosenpass-Team so etwas plant, wissen wir nicht, und ganz umsonst wäre es nicht. Sobald wieder Traffic fliesst, müsste WireGuard entweder auf einen frischen Schlüssel warten, womit die ersten Pakete die Round Trips von Rosenpass abwarten müssten, oder mit einem älteren Schlüssel weitermachen.

Planen Sie jetzt die Migration Ihrer VPNs auf Post-Quantum-Kryptografie, und schützen Sie die internen Dienste zusätzlich unabhängig vom Tunnel. Am Anfang steht ein kryptografisches Inventar: Welche Tunnel nutzen noch einen klassischen Schlüsselaustausch, und welche internen Dienste verlassen sich für ihre Vertraulichkeit auf sie?