You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/blog/2025-06-30-post-quantum-roadmap.en.md
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ First, let's take a look at the ciphers involved in Cryptomator:
29
29
<figcaption>Cryptographic Breakdown of Cryptomator & Hub</figcaption>
30
30
</figure>
31
31
32
-
As you can see, we mostly rely on AES- and EC-based algorithms. These are considered traditional algorithms, so their security assumptions refer to a world of traditional (non-quantum) computers. The general idea is that computations are easy if you know the right key but practically impossible without. When I say "practically impossible" I mean on traditional computers, as the computations are just "too complex".
32
+
As you can see, we mostly rely on AES- and EC-based algorithms. These are traditional algorithms whose security assumptions apply in a world of classical (non-quantum) computers. The general idea is that computations are efficient if you know the right key but practically impossible without. When I say "practically impossible" I mean on traditional computers, as the computations are just "too complex".
33
33
34
34
## A Few Words About Complexity
35
35
@@ -47,13 +47,13 @@ When we want to express how many steps a certain computation requires, we catego
47
47
48
48
To ensure that breaking a cipher requires an insane amount of time and energy, cryptographic algorithms rely on hard-to-compute problems—i.e., we're operating on the more complex side of the spectrum.
49
49
50
-
The most illustrative example for this is the factorization problem: Determine the prime factors of 8633. The result is easy to verify through a simple multiplication (89 × 97), but finding the factors from the product is hard; [harder than polynomial but subexponential](https://en.wikipedia.org/wiki/General_number_field_sieve). This is exactly what the RSA crypto scheme is based on (except with some *very* large numbers), where the public key essentially is the product of two secret primes that are required to compute the private key.
50
+
The most illustrative example for this is the factorization problem: Determine the prime factors of 8633. The result is easy to verify through a simple multiplication (89 × 97), but finding the factors from the product is hard; [harder than polynomial but subexponential](https://en.wikipedia.org/wiki/General_number_field_sieve). This is exactly what the RSA crypto scheme is based on (except with some *very* large numbers), where the public key includes the product of two secret primes that are required to compute the private key.
51
51
52
52
## How Quantum Computers Weaken Ciphers
53
53
54
54
### Asymmetric Cryptography
55
55
56
-
Quantum computers are not inherently faster, but they allow for a different set of algorithms to run. So, if a certain problem is proven to be complex using traditional algorithms, quantum algorithms may be significantly less complex in terms of computational costs.
56
+
Quantum computers are not inherently faster, but they allow for a different set of algorithms to run. So, while a problem may be hard-to-compute for traditional algorithms, it could be far less complex when solved with quantum algorithms.
57
57
58
58
One of the most infamous examples is [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), which solves the factorization problem in polynomial time. While polynomial time is just one row above exponential time in the table above, it makes all the difference. The following graph illustrates the effect of an increasing problem size on the two complexity classes:
59
59
@@ -70,7 +70,7 @@ Imagine a number lock with four digits. To guess the correct combination, a trad
70
70
71
71
More generally, when a traditional algorithm takes \(n/2\) steps on average, a quantum computer only needs \(\sqrt n\) attempts—a speed-up that the BBBV theorem proves to be the best possible solution. If you want to understand how this works, there's [a great video by 3Blue1Brown about Grover's Algorithm](https://www.youtube.com/watch?v=RQWpF2Gb-gU).
72
72
73
-
This "magic" applies to any problem where one can efficiently verify whether a guessed input is correct. That's obviously a problem if you don't want an attacker to guess your secret key. Fortunately, the defense is simple: increase \(n\) to a size where even \(\sqrt n\) becomes large enough to make Grover's algorithm impractical.
73
+
This "magic" applies to any problem where it's efficient to check if a guessed solution is correct. That's obviously a problem if you don't want an attacker to guess your secret key. Fortunately, the defense is simple: increase \(n\) to a size where even \(\sqrt n\) becomes large enough to make Grover's algorithm impractical.
74
74
75
75
> [!QUESTION] Why is AES-256 quantum-secure?
76
76
> Ever wondered why we use AES-256 instead of AES-128?
@@ -86,7 +86,7 @@ This "magic" applies to any problem where one can efficiently verify whether a g
86
86
<figcaption>Kyber and Dilithium</figcaption>
87
87
</figure>
88
88
89
-
So, while a sufficiently large key space is enough in the symmetric world, asymmetric ciphers need to be replaced to withstand attacks from quantum computers. In 2016, the National Institute of Standards and Technology (NIST) launched a competition to identify quantum-resistant cryptographic algorithms.
89
+
So, while a sufficiently large key space is enough for AES, our asymmetric ciphers need to be replaced to withstand attacks from quantum computers. In 2016, the National Institute of Standards and Technology (NIST) launched a competition to identify quantum-resistant cryptographic algorithms.
90
90
91
91
Electing algorithms through a competition has already proven successful in the past, as with AES and SHA-3. This approach attracts significant attention from experts, who do their best to uncover weaknesses.
92
92
@@ -140,7 +140,7 @@ In the security sector, standardization is even more critical. Algorithms, proto
140
140
141
141
Ignoring such standards—sometimes in the name of speed or convenience—sets you on a path that may be paved with hidden flaws. Even the smallest change can introduce serious vulnerabilities that, without thorough peer reviews, are likely to be discovered first by someone smarter and less well-intentioned.
142
142
143
-
At Cryptomator, we've always stood agains "security through obscurity" (which is also [why open source matters](https://cryptomator.org/guides/open-source/)). Needless to say, we've never used home-cooked ciphers—that would pose a serious risk. And the more widely used an algorithm or protocol is, the easier it becomes to understand, verify, and audit the system as a whole.
143
+
At Cryptomator, we've always stood against "security through obscurity" (which is also [why open source matters](https://cryptomator.org/guides/open-source/)). Needless to say, we've never used home-cooked ciphers—that would pose a serious risk. And the more widely used an algorithm or protocol is, the easier it becomes to understand, verify, and audit the system as a whole.
144
144
145
145
### A Strong Foundation
146
146
@@ -170,7 +170,7 @@ So, if all the ciphers used in Cryptomator products—as well as the exchange of
170
170
171
171
While we use well-established cryptography, the file formats themselves are our own. But we want to change that. Some time ago, we joined forces with developers of Cyberduck, gocryptfs, and rclone to derive a common format for encrypted directories—ensuring interoperability across our tools. Although the format is still a work in progress, we hope to share more details with you in a couple of months. In the meantime, you're of course invited to review the format and contribute ideas for improvement on [GitHub](https://github.com/encryption-alliance/unified-vault-format).
172
172
173
-
One key benefit of this *Unified Vault Format* is that it enables key rotation—which itself brings two major advatages:
173
+
One key benefit of this *Unified Vault Format* is that it enables key rotation—which itself brings two major advantages:
174
174
175
175
1.**Access revocation**: After rotating keys, former vault members can no longer decrypt files added after their access got revoked. What is trivial with access control lists requires special care when we want to enforce this cryptographically.
176
176
2.**Cipher agility**: To some extent, it enables cipher upgrades. For example, if a vulnerability is found in one algorithm, we can flip a switch and transition to a new JWE algorithm—instantly protecting all newly added files.
@@ -183,4 +183,4 @@ As explained above, Cryptomator is already quantum-secure. Since it uses only sy
183
183
184
184
### Cryptomator Hub
185
185
186
-
We are currently in the process of implementing X-Wing and HPKE-7 in JWE libraries. As a 100% open-source company, we have always contributed to other libraries and projects. So it comes as no surprise that we are now in close contact with the maintainers of one of the most widely used [JOSE libraries for Java](https://connect2id.com/products/nimbus-jose-jwt), the authors of [JOSE HPKE RFC](https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07) and the [X-Wing RFC](https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/) as well as the JDK security team, contributing these new standard to upstream projects as for example with [X-Wing support in the OpenJDK](https://github.com/openjdk/jdk/pull/26032). All to collaboratively build the necessary foundation for the years to come.
186
+
We are currently in the process of implementing X-Wing and HPKE-7 in JWE libraries. As a 100% open-source company, we have always contributed to other libraries and projects. So it comes as no surprise that we are now in close contact with the maintainers of one of the most widely used [JOSE libraries for Java](https://connect2id.com/products/nimbus-jose-jwt), the authors of [JOSE HPKE RFC](https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke-07) and the [X-Wing RFC](https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/) as well as the JDK security team, contributing these new standard to upstream projects such as [X-Wing support in the OpenJDK](https://github.com/openjdk/jdk/pull/26032). All to collaboratively build a resilient foundation for the years ahead.
0 commit comments