Unser Fahrplan zur Post-Quanten-Kryptografie
Wenn du dies liest, hast du wahrscheinlich schon von Quantencomputern gehört und davon, dass sie eines Tages einige traditionelle Verschlüsselungsverfahren brechen könnten. In diesem Artikel erklären wir, wie sich dies auf Cryptomator auswirkt und was unser Plan ist, um vollständig quantensicher zu werden.
Derzeit verwendete Algorithmen
Werfen wir zunächst einen Blick auf die in Cryptomator verwendeten Verschlüsselungsverfahren:
Wie du sehen kannst, verlassen wir uns hauptsächlich auf AES- und EC-basierte Algorithmen. Dies sind traditionelle Algorithmen, deren Sicherheitsannahmen in einer Welt klassischer (nicht-quantenbasierter) Computer gelten. Die Grundidee ist, dass Berechnungen effizient sind, wenn man den richtigen Schlüssel kennt, aber ohne ihn praktisch unmöglich. Wenn ich „praktisch unmöglich“ sage, meine ich auf traditionellen Computern, da die Berechnungen einfach „zu komplex“ sind.
Ein paar Worte zur Komplexität
Während wir Komplexität vermeiden, wenn es um Benutzerfreundlichkeit oder Code-Lesbarkeit geht, gibt es eine bestimmte Art von Komplexität, die wir anstreben. Lass mich das erklären:
Wenn wir ausdrücken wollen, wie viele Schritte eine bestimmte Berechnung erfordert, kategorisieren wir Algorithmen in Klassen von Rechenkomplexität. Zur Veranschaulichung hier ein paar Beispiele mit Hunden:
Komplexitätsklasse | Beispiel | O‑Notation |
---|---|---|
Konstante Zeit | Eine Hundepfeife zu nutzen, dauert immer gleich lang, egal wie viele Hunde zuhören. | O(1) |
Logarithmische Zeit | Die Telefonnummer einer Tierklinik im Telefonbuch zu finden ist einfach, da es alphabetisch sortiert ist und man die Seiten schnell eingrenzen kann. | O(log n) |
Lineare Zeit | Jeden Hund streicheln. Wenn jeder Hund gleich viel Aufmerksamkeit bekommt, dauert es genau n-mal so lange, wenn du n Hunde hast. | O(n) |
Polynomielle Zeit | Wenn jeder Hund auf einer Party jeden anderen Hund beschnuppern und begrüßen will. Hund 1 schnuppert an Hund 2, 3, 4, … Hund 2 schnuppert an Hund 3, 4, … und so weiter. | O(nᵏ) |
Exponentielle Zeit | Jeder Hund bekommt 4 Welpen. Das ergibt 16 Hunde nach zwei Generationen, 64 nach drei und 256 nach vier Generationen. | O(kⁿ) |
Um sicherzustellen, dass das Knacken eines Verschlüsselungsverfahrens extrem viel Zeit und Energie benötigt, beruhen kryptografische Algorithmen auf schwer berechenbaren Problemen – wir bewegen uns also auf der komplexeren Seite des Spektrums.
Das wohl anschaulichste Beispiel ist das Faktorisierungsproblem: Bestimme die Primfaktoren von 8633. Die Lösung ist einfach zu überprüfen (89 × 97), aber die Faktoren aus dem Produkt zu ermitteln, ist sehr schwer – schwerer als polynomiell, aber subexponentiell. Genau darauf basiert das RSA-Verschlüsselungsverfahren (nur mit viel größeren Zahlen), wobei der öffentliche Schlüssel das Produkt zweier geheimer Primzahlen enthält, die zur Berechnung des privaten Schlüssels erforderlich sind.
Wie Quantencomputer Verschlüsselungen schwächen
Asymmetrische Kryptografie
Quantencomputer sind nicht grundsätzlich schneller, aber sie ermöglichen die Ausführung eine andere Klasse von Algorithmen. Ein Problem, das auf klassischen Computern als komplex gilt, kann auf einem Quantencomputer deutlich einfacher sein.
Ein besonders bekanntes Beispiel ist der Shor-Algorithmus, der das Faktorisierungsproblem in polynomieller Zeit löst. Auch wenn polynomieller Zeit nur eine Zeile über exponentieller Zeit in der obigen Tabelle steht, macht das einen gewaltigen Unterschied. Die folgende Grafik veranschaulicht die Auswirkung einer zunehmenden Problemgröße auf die beiden Komplexitätsklassen:
Wenn ein Quantencomputer gebaut werden kann, der Shors Algorithmus auf große Zahlen anwendet, würde das die meisten heute verwendeten Public-Key-Verfahren – einschließlich ECDH – brechen.
Symmetrische Kryptografie
Stell dir ein Zahlenschloss mit vier Ziffern vor. Um die richtige Kombination zu erraten, müsste ein herkömmlicher Computer jede Möglichkeit überprüfen, beginnend mit 0000 und endend mit 9999. Im Durchschnitt würde dies 5.000 Versuche erfordern. Was wenn ich dir sagen würde, dass ein Quantencomputer dies mit nur 100 Versuchen schaffen könnte? Klingt wie Zauberei? Genau das kann der Grover-Algorithmus leisten.
Allgemeiner gesagt: Wenn ein herkömmlicher Algorithmus durchschnittlich \(n/2\) Schritte benötigt, braucht ein Quantencomputer nur \(\sqrt n\) Versuche – eine Beschleunigung, die laut dem BBBV-Theorem das absolute Optimum darstellt. Wenn du verstehen möchtest, wie das funktioniert, gibt es ein großartiges Video von 3Blue1Brown über Grovers Algorithmus.
Diese „Magie" gilt für jedes Problem, bei dem sich eine vermutete Lösung effizient überprüfen lässt. Das ist natürlich etwas ärgerlich, wenn du nicht möchtest, dass ein Angreifer deinen geheimen Schlüssel errät. Glücklicherweise ist die Abwehr einfach: Erhöhe \(n\) auf eine Größe, bei der selbst \(\sqrt n\) groß genug wird, um Grovers Algorithmus unpraktikabel zu machen.
Hast du dich jemals gefragt, warum wir AES-256 anstelle von AES-128 verwenden?
Die „256” bezieht sich auf die Anzahl der Schlüsselbits, was zu \(2^{256}\) möglichen Schlüsseln führt. Das Erraten des richtigen Schlüssels würde daher \(2^{256} / 2 = 2^{255}\) Versuche auf einem herkömmlichen Computer und \(\sqrt{2^{256}} = 2^{128}\) Versuche mit Grovers Algorithmus erfordern.
\(2^{128}\) Versuche sind schlichtweg zu viele. Daher reicht AES-128 bei Angriffen mit herkömmlichen Computern, während die Post-Quanten-Welt AES-256 erforderlich macht.
Eine neue Ära der Verschlüsselung

Während also für AES ein ausreichend großer Schlüsselraum genügt, müssen unsere asymmetrischen Verschlüsselungsverfahren ersetzt werden, um Angriffen durch Quantencomputer standhalten zu können. Im Jahr 2016 startete das National Institute of Standards and Technology (NIST) einen Wettbewerb zur Ermittlung quantenresistenter kryptografischer Algorithmen.
Die Auswahl von Algorithmen im Rahmen eines Wettbewerbs hat sich bereits in der Vergangenheit bewährt, wie beispielsweise bei AES und SHA-3. Dieser Ansatz stößt bei Experten auf großes Interesse, die ihr Bestes geben, um Schwachstellen aufzudecken.
Im Jahr 2022, nach mehreren Runden, in denen Dutzende von Kandidaten ausgeschieden waren, gab das NIST die Gewinner bekannt. Kyber und Dilithium – benannt nach Kristallen aus Star Wars bzw. Star Trek – wurden die ersten standardisierten Post-Quanten-Algorithmen für Verschlüsselung und digitale Signaturen. Sie erhielten offiziell die Namen ML-KEM und ML-DSA.
Hier ist noch einmal ein tolles Video, das die zugrunde liegende Mathematik der ML-basierten Kryptografie erklärt.
Perfekt! Integrieren wir also ML-KEM und ML-DSA in Cryptomator Hub:
Jetzt sagst du sicher: „Aber Moment mal, da ist doch noch ECDH drin!?". Und du hast recht. Obwohl die neuen Verschlüsselungsalgorithmen sehr vielversprechend sind, müssen wir uns der Tatsache stellen, dass es sie einfach noch nicht lange gibt. Wir wissen aufgrund der Neuargikeit einfach noch nicht, welche Arten von Angriffen in Zukunft entdeckt werden könnten – und ob diese Algorithmen sich wirklich bewähren.
Um besonders vorsichtig zu sein, kombinieren wir daher eine traditionelle Verschlüsselung mit einer post-quantenbasierten. Stell dir das wie eine Tür mit zwei Schlössern vor: Wenn eines aufgebrochen wird, schützt das andere weiterhin den Inhalt. Es ist ein einfaches Design, das sicherstellt, dass das System nicht schwächer ist als seine einzelnen Komponenten. Diese Post-Quanten-/Traditionelle (PQ/T)-Hybridverschlüsselung wird X-Wing genannt.

X-Wing befindet sich noch in Entwicklung. Ich habe die RFC-Autoren – Deirdre Connolly, Peter Schwabe und Bas Westerbaan – gefragt, wann die finale Spezifikation veröffentlicht wird. Zehn Minuten später kam folgende Antwort von Bas:
X-Wing is final and being shipped by Google and Apple presumably in hardware.
(X-Wing ist final und wird bereits von Google und Apple implementiert, voraussichtlich in Hardware.)
— Bas Westerbaan
Zur Sicherheit fragte ich noch, ob Änderungen an der aktuellen Spezifikation geplant seien:
No significant changes, no changes planned or expected at all.
(Keine signifikanten Änderungen, nichts geplant oder erwartet.)
— Deirdre Connolly
Dies bestätigte unsere Überzeugung, dass jetzt der perfekte Zeitpunkt ist, um X-Wing als zukünftigen Standard für die Schlüsselkapselung einzuführen.
Ja, es gibt auch Bemühungen, eine Kombination aus ML-DSA und ECDSA zu standardisieren. Im Gegensatz zu X-Wing befindet sich dies jedoch in einer früheren Phase. Wir verfolgen die Entwicklungen in diesem Bereich genau und werden dieses Schema wahrscheinlich nutzen, sobald es bereit ist.
Standardisierung der Kryptografie
Warum Standards wichtig sind
In jeder Branche spielt Standardisierung eine wichtige Rolle. Sie gewährleistet Kompatibilität, fördert Interoperabilität und senkt Kosten, indem sie es verschiedenen Systemen und Organisationen ermöglicht, mithilfe gemeinsamer Protokolle und Spezifikationen zusammenzuarbeiten – und dabei Konsistenz und Zuverlässigkeit zu gewährleisten.
In der IT-Sicherheit ist Standardisierung sogar noch wichtiger. Algorithmen, Protokolle und Datenformate müssen nicht nur über heterogene Systeme hinweg zuverlässig funktionieren, sondern auch strengen Prüfungen standhalten. Je mehr Experten einen Standard begutachten, desto besser. Wie bei den zuvor erwähnten NIST-Wettbewerben können solche Prüfungen Schwachstellen aufdecken, bevor eine Verschlüsselung produktiv eingesetzt wird. Durch die Einhaltung etablierter, transparenter Standards profitieren sowohl Entwickler als auch Anwender von einem stärkeren, vertrauenswürdigeren Schutz – insbesondere angesichts der sich stetig weiterentwickelnden Bedrohungslandschaft, wie z.B. aufgrund von Quantencomputern.
Das Ignorieren solcher Standards – manchmal Bequemlichkeit oder für vermeintliche Geschwindigkeitsvorteile – führt auf einen Pfad, der mit versteckten Mängeln gepflastert sein kann. Selbst die kleinste Änderung kann schwerwiegende Schwachstellen mit sich bringen, die ohne gründliche Peer-Reviews wahrscheinlich zuerst von jemandem entdeckt werden, der klüger ist und weniger gute Absichten hat.
Bei Cryptomator haben wir uns immer gegen „Security through Obscurity” ausgesprochen (was auch der Grund ist, warum Open Source so wichtig ist). Selbstverständlich haben wir nie selbst entwickelte Chiffren verwendet – ein absolutes No-Go. Und je weiter verbreitet ein Algorithmus oder Protokoll ist, desto einfacher wird es, das System als Ganzes zu verstehen, zu überprüfen und zu auditieren.
Ein starkes Fundament
Viele Standards bauen auf anderen auf. Ohne ML-KEM gäbe es kein X-Wing. Nun, da X-Wing kurz vor der Einführung steht, was können wir damit machen? Es in einem weiteren Standard verwenden: HPKE.
HPKE steht für Hybrid Public Key Encryption – und um genau zu sein, hängt es überhaupt nicht von X-Wing ab. Stattdessen definiert es, wie drei verschiedene kryptografische Komponenten – KEM, KDF und AEAD – auf eine bestimmte Weise kombiniert werden, um klar definierte Sicherheitseigenschaften zu gewährleisten. Und X-Wing kann als eine dieser Komponenten (KEM) dienen.
Ein weiterer Standard, den wir schätzen gelernt haben, ist JWE, ein Datenformat für den Austausch verschlüsselter Nutzdaten. Und glücklicherweise arbeitet grade eine Gruppe Experten daran, die Verwendung von X-Wing-basiertem HPKE in JWE zu standardisieren. Genau das wollen wir in Cryptomator Hub übernehmen und damit die aktuellen ECDH-basierten JWEs ersetzen.
Über die oben genannten Vorteile von Peer-Reviews hinaus bietet die Verwendung standardisierter Formate gegenüber proprietären Formaten mehrere zusätzliche Vorteile:
- Gemeinsame APIs erleichtern den Austausch von Implementierungen – beispielsweise bleibt die Verwendung von HPKE unabhängig von den zugrunde liegenden Algorithmen gleich.
- Breite Verfügbarkeit etablierter Bibliotheken. So gibt es beispielsweise Dutzende von JWE/JWT-Bibliotheken.
- Offizielle Testvektoren ermöglichen es uns, Tests zu schreiben, die den Build frühzeitig abbrechen, wenn etwas schief geht.
- Schnellere Erkennung von Schwachstellen: Wenn ein Fehler in einem weit verbreiteten Standard entdeckt wird, wird er wahrscheinlich schnell gemeldet – während eine einzelne proprietäre Implementierung möglicherweise viel länger unbemerkt bleibt.
Sowohl JWE als auch HPKE unterstützen austauschbare interne Algorithmen bei gleichbleibender externer Schnittstelle. Dies ermöglicht es uns, die Gesamtstruktur beizubehalten und interne Komponenten schnell zu ersetzen, wenn Schwachstellen auftreten.
The moral is the need for cryptographic agility. It’s not enough to implement a single standard; it’s vital that our systems be able to easily swap in new algorithms when required.
(Die Moral von der Geschichte ist die Notwendigkeit kryptografischer Agilität. Es reicht nicht aus, einen einzigen Standard zu implementieren; es ist entscheidend, dass unsere Systeme bei Bedarf problemlos neue Algorithmen einbinden können.)
Standardisierung des Tresorformats
Wenn also alle in Cryptomator-Produkten verwendeten Verschlüsselungsalgorithmen – sowie der Austausch von Geheimnissen im Cryptomator Hub – auf Standards basieren, wie sieht es dann mit dem Tresorformat aus?
Wir verwenden zwar bewährte Kryptografie, aber die Dateiformate selbst sind unsere eigenen. Das möchten wir jedoch ändern. Vor einiger Zeit haben wir uns mit den Entwicklern von Cyberduck, gocryptfs und rclone zusammengetan, um ein gemeinsames Format für verschlüsselte Verzeichnisse zu entwickeln und so die Interoperabilität unserer Tools sicherzustellen. Das Format befindet sich zwar noch in der Entwicklung, aber wir hoffen, in ein paar Monaten weitere Details mitteilen zu können. In der Zwischenzeit bist du natürlich herzlich eingeladen, das Format zu überprüfen und Verbesserungsvorschläge auf GitHub einzureichen.
Ein wesentlicher Vorteil dieses Unified Vault Format ist, dass es eine Schlüsselrotation ermöglicht, was wiederum zwei wesentliche Vorteile mit sich bringt:
- Zugriffssperre: Nach der Rotation der Schlüssel können ehemalige Mitglieder des Tresors keine Dateien mehr entschlüsseln, die nach dem Widerruf ihres Zugriffs hinzugefügt wurden. Was bei ACL-basierter Zugriffskontrolle trivial ist, erfordert besondere Sorgfalt, wenn wir dies kryptografisch forcieren wollen.
- Flexibilität bei der Verschlüsselung: Bis zu einem gewissen Grad ermöglicht es Verschlüsselungs-Upgrades. Wenn beispielsweise eine Schwachstelle in einem Algorithmus gefunden wird, können wir einen Schalter umlegen und zu einem neuen JWE-Algorithmus übergehen – wodurch alle neu hinzugefügten Dateien sofort geschützt sind.
Kurz gesagt: Wo stehen wir?
Cryptomator
Wie oben erläutert, ist Cryptomator bereits quantensicher. Da es ausschließlich symmetrische Verschlüsselungsalgorithmen mit ausreichend großen Schlüsselräumen verwendet, stellen Quantencomputer derzeit keine bekannte Bedrohung dar.
Cryptomator Hub
Cryptomator Hub muss hingegen auf andere Algorithmen umgestellt werden. Dies sind die Schritte, die wir unternehmen:
- (In Bearbeitung) Implementierung von X-Wing: Als auf Open Source fokussiertes Unternehmen haben wir schon immer zu anderen Projekten beigetragen. Wie bereits erwähnt, stehen wir in Kontakt mit den Autoren des X-Wing RFC und auch mit dem JDK Security Team, um X-Wing-Unterstützung zum OpenJDK hinzuzufügen.
- (In Bearbeitung) Implementierung von HPKE in JWE-Bibliotheken: Seit den Anfängen von Cryptomator haben wir zu einer der am weitesten verbreiteten JOSE-Bibliotheken für Java beigetragen. Es liegt daher nahe, dass wir HPKE-Unterstützung (und anschließend X-Wing-basierte HPKE) gemäß dem JOSE HPKE RFC hinzuzufügen. Die Autoren des RFC (von denen wir einen persönlich kennen) sind bereits gespannt auf unser Feedback.
- Migration der in Cryptomator Hub verwendeten JWEs von traditioneller Kryptographie zu PQ/T-Hybriden. Wir möchten damit beginnen, sobald die Standards final veröffentlicht sind und die oben genannten Implementierungen in Upstream-Bibliotheken gemerged werden können.
- Einführung eines neuen Tresorformats, das die Cipher Agility verbessert und weitere Vorteile für Cryptomator Hub-Benutzer bietet.
Wie du siehst, handelt es sich hierbei um ein projektübergreifendes Unterfangen. All dies, um gemeinsam eine robuste Grundlage für die kommenden Jahre zu schaffen.