Harvest now, decrypt later

Harvest now, decrypt later bezeichnet ein Angriffsmuster, bei dem verschlüsselte Daten heute aufgezeichnet und aufbewahrt werden, um sie zu einem späteren Zeitpunkt zu entschlüsseln — dann nämlich, wenn ein Rechner zur Verfügung steht, der die verwendete Schlüsseleinigung brechen kann.

Der Angriff braucht keine Schwachstelle im System und hinterlässt dort auch keine Spur. Er verlangt nur Zugang zum Übertragungsweg und Speicherplatz, und beides ist für einen staatlichen Angreifer kein Hindernis.

Warum das Mitschneiden genügt

Verschlüsselter Verkehr im Internet wird fast immer in zwei Schritten geschützt: Beide Seiten einigen sich zunächst auf einen gemeinsamen Sitzungsschlüssel, meist über Diffie-Hellman oder ein Verfahren über elliptische Kurven, und verschlüsseln die Nutzdaten anschließend symmetrisch.

Shors Algorithmus bricht den ersten Schritt vollständig. Wer den Verbindungsaufbau mitgeschnitten hat, kann den Sitzungsschlüssel nachträglich ausrechnen und damit den gesamten aufgezeichneten Verkehr öffnen. Die symmetrische Verschlüsselung der Nutzdaten selbst ist dabei gar nicht das Ziel — sie bleibt bei ausreichender Schlüssellänge auch gegen Quantenrechner stabil.

Vertraulichkeit ist betroffen, Authentizität nicht

Daraus folgt eine Asymmetrie, die für die Priorisierung der Umstellung entscheidend ist.

Vertraulichkeit ist rückwirkend angreifbar. Was heute übertragen wird, kann in zehn Jahren gelesen werden. Der Schaden entsteht später, verursacht wird er jetzt.

Signaturen sind es nicht. Eine Unterschrift muss zu dem Zeitpunkt fälschungssicher sein, an dem sie geprüft wird. Ein Quantenrechner, der in zehn Jahren eine Signatur von heute fälschen könnte, nützt wenig — das Dokument ist längst angenommen oder abgelehnt. Signaturverfahren müssen rechtzeitig gewechselt werden, aber sie tragen keine Altlast.

Langfristige Signaturen sind die Ausnahme: Wo eine Unterschrift über Jahrzehnte gültig bleiben soll, etwa bei Archivgut, greift dieselbe Logik wie bei der Vertraulichkeit.

Die Rechnung dahinter

Wie dringend der Wechsel ist, lässt sich abschätzen, indem man drei Zeiträume nebeneinanderlegt: wie lange die Daten vertraulich bleiben müssen, wie lange die eigene Umstellung dauert, und wann ein ausreichend leistungsfähiger Quantenrechner verfügbar sein wird. Übersteigt die Summe der ersten beiden den dritten Wert, ist man zu spät dran — und zwar bereits heute, nicht erst dann.

Das BSI geht in seiner zuletzt 2025 aktualisierten Studie zum Entwicklungsstand davon aus, dass ein kryptografisch relevanter Quantenrechner in höchstens fünfzehn Jahren realisierbar ist, also bis 2040 oder früher. Im Hochsicherheitsbereich arbeitet die Bundesregierung mit der Annahme, dass dies zu Beginn der 2030er Jahre der Fall sein könnte.

Wen es zuerst trifft

Die Leitlinie zur PQC-Umstellung nennt als besonders gefährdet Daten, deren Vertraulichkeit über lange Zeit geschützt bleiben muss: Verschlusssachen, sensible personenbezogene Daten und Geschäftsgeheimnisse. Dazu kommen Systeme mit langer Lebensdauer, bei denen die Umstellung selbst Jahre braucht — auch ohne Aufzeichnung droht dort, dass der Wechsel nicht rechtzeitig fertig wird.

Was hilft und was nicht

Wirksam ist allein, die Schlüsseleinigung selbst quantensicher zu machen, und zwar bevor der Verkehr entsteht. Das BSI verlangt dafür hybride Verfahren, die ein klassisches und ein post-quanten-sicheres Verfahren kombinieren, sodass der Schlüssel sicher bleibt, solange eines von beiden hält.

Perfect Forward Secrecy hilft hier nicht, und das wird regelmäßig verwechselt. PFS schützt frühere Sitzungen davor, dass ein später kompromittierter Langzeitschlüssel sie nachträglich öffnet. Gegen einen Angreifer, der die Schlüsseleinigung selbst brechen kann, greift dieser Schutz nicht — er rechnet den Sitzungsschlüssel ja direkt aus.

Zur Benennung

Verbreitet sind beide Formen. Im englischsprachigen Raum überwiegt „harvest now, decrypt later", auch als HNDL abgekürzt; deutsche Behördendokumente einschließlich der PQC-Leitlinie schreiben durchgängig „store now, decrypt later". Gemeint ist dasselbe.