6 ms·

It should be noted that if indeed there has not remained much time until a usable quantum computer will become available, the priority is the deployment of FIPS

It should be noted that if indeed there has not remained much time until a usable quantum computer will become available, the priority is the deployment of FIPS 203 (ML-KEM) for the establishment of the secret session keys that are used in protocols like TLS or SSH. ML-KEM is intended to replace the traditional and the elliptic-curve variant of the Diffie-Hellman algorithm for creating a shared secret value. When FIPS 203, i.e. ML-KEM is not used, adversaries may record data transferred over the Internet and they might become able to decrypt the data after some years. On the other hand, there is much less urgency to replace the certificates and the digital signature methods that are used today, because in most cases it would not matter if someone would become able to forge them in the future, because they cannot go in the past to use that for authentication. The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them. OpenSSH, OpenSSL and many other cryptographic libraries and applications already support FIPS 203 (ML-KEM), so it could be easily deployed, at least for private servers and clients, without also replacing the existing methods used for authentication, e.g. certificates, where using post-quantum signing methods would add a lot of overhead, due to much bigger certificates.

FiloSottile 7mo ago
That was my position until last year, and pretty much a consensus in the industry. What changed is that the new timeline might be so tight that (accounting for specification, rollout, and rotation time) the time to switch authentication has also come. ML-KEM deployment is tangentially touched on in the article because it's both uncontroversial and underway, but: > This is not the article I wanted to write. I’ve had a pending draft for months now explaining we should ship PQ key exchange now, but take the time we still have to adapt protocols to larger signatures, because they were all designed with the assumption that signatures are cheap. That other article is now wrong, alas: we don’t have the time if we need to be finished by 2029 instead of 2035. > For key exchange, the migration to ML-KEM is going well enough but: 1. Any non-PQ key exchange should now be considered a potential active compromise, worthy of warning the user like OpenSSH does, because it’s very hard to make sure all secrets transmitted over the connection or encrypted in the file have a shorter shelf life than three years. [...] You comment is essentially the premise of the other article.
- adrian_b 7mo ago
  I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately. However that does not mean that the switch should really be done as soon as it is possible, because it would add unnecessary overhead. This could be done by distributing a set of post-quantum certificates, while continuing to allow the use of the existing certificates. When necessary, the classic certificates could be revoked immediately.
  - FiloSottile 7mo ago
    How do you do revocation or software updates securely if your current signature algorithm is compromised?
    - ekr____ 7mo ago
      As a practical matter, revocation on the Web is handled mostly by centrally distributed revocation lists (CRLsets, CRLite, etc. [0]), so all you really need is: (1) A PQ-secure way of getting the CRLs to the browser vendors. (2) a PQ-secure update channel. Neither of these require broad scale deployment. However, the more serious problem is that if you have a setting where most servers do not have PQ certificates, then disabling the non-PQ certificates means that lots of servers can't do secure connections at all. This obviously causes a lot of breakage and, depending on the actual vulnerability of the non-PQ algorithms, might not be good for security either, especially if people fall back to insecure HTTP. See: https://educatedguesswork.org/posts/pq-emergency/ https://educatedguesswork.org/posts/pq-emergency/ and https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap https://www.chromium.org/Home/chromium-security/post-quantum... [0] The situation is worse for Apple.
      - FiloSottile 7mo ago
        Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time the switchover.
layer8 7mo ago
> The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them. This very much exists. In particular, the cryptographic timestamps that are supposed to protect against future tampering are themselves currently using RSA or EC.
- ekr____ 7mo ago
  Yes, though we do know how to solve this problem by using hash-based timestamping systems. See: https://link.springer.com/article/10.1007/BF00196791 https://link.springer.com/article/10.1007/BF00196791 Of course, the modern version of this is putting the timestamp and a hash of the signature on the blockchain.
Perseids 7mo ago
Super important: Don't replace traditional (elliptic curve) Diffie-Hellman with ML-KEM, but enhance it by using hybrid key exchanges. Done thusly, you need to break both the classical and post-quantum cryptography to launch an attack. If you worry about a >=1% risk of quantum attacks being available soon, you should also worry about a >=1% risk of the relatively new ML-KEM being broken soon. The risk profile is pretty comparable. For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated. Filippo has linked opinions that quantum attacks are right around the corner. People like Dan Bernstein (djb) are throwing all their weight to stress that anything but hybrids are irresponsible. I don't think there is anybody that says "hybrids are a bad idea", just people that want to make it easy to choose non-hybrid ML-KEM.
- pie_flavor 7mo ago
  How do you mean the risk profile is comparable, when ECDH is nearly guaranteed to be broken in five years and Kyber is two decades old? The two have nothing to do with each other, the ECDH component of a hybrid becomes worthless before you next replace your smartphone, and bloating the protocol can only hurt adoption. Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean you have to repeat it uncritically.
  - littlestymaar 7mo ago
    > when ECDH is nearly guaranteed to be broken in five years Says who? There's a big difference between “we can't be sure that ECDH stays secure for five more years” and “ECDH is nearly guaranteed to be broken”. There has been two major papers in the beginning of the year that advanced the state of the art enough to question the prior assumption about the slowness of QC progress. Now we know that rapid advances are possible and we must take that into account in risk assessment. But that doesn't mean that rapid advances are guaranteed. Things could stay stagnant for 15 more years at this point before the next breakthrough. And if that's the case, then ECDH could very well remain relevant for the remaining century. We just cannot know if it happens, so we can't take the risk. But that doesn't mean that we are certain that the risk will materialize.

FiloSottile 7mo ago

That was my position until last year, and pretty much a consensus in the industry. What changed is that the new timeline might be so tight that (accounting for specification, rollout, and rotation time) the time to switch authentication has also come. ML-KEM deployment is tangentially touched on in the article because it's both uncontroversial and underway, but: > This is not the article I wanted to write. I’ve had a pending draft for months now explaining we should ship PQ key exchange now, but take the time we still have to adapt protocols to larger signatures, because they were all designed with the assumption that signatures are cheap. That other article is now wrong, alas: we don’t have the time if we need to be finished by 2029 instead of 2035. > For key exchange, the migration to ML-KEM is going well enough but: 1. Any non-PQ key exchange should now be considered a potential active compromise, worthy of warning the user like OpenSSH does, because it’s very hard to make sure all secrets transmitted over the connection or encrypted in the file have a shorter shelf life than three years. [...] You comment is essentially the premise of the other article.

adrian_b 7mo ago
I agree with you that one must prepare for the transition to post-quantum signatures, so that when it becomes necessary the transition can be done immediately. However that does not mean that the switch should really be done as soon as it is possible, because it would add unnecessary overhead. This could be done by distributing a set of post-quantum certificates, while continuing to allow the use of the existing certificates. When necessary, the classic certificates could be revoked immediately.
- FiloSottile 7mo ago
  How do you do revocation or software updates securely if your current signature algorithm is compromised?
  - ekr____ 7mo ago
    As a practical matter, revocation on the Web is handled mostly by centrally distributed revocation lists (CRLsets, CRLite, etc. [0]), so all you really need is: (1) A PQ-secure way of getting the CRLs to the browser vendors. (2) a PQ-secure update channel. Neither of these require broad scale deployment. However, the more serious problem is that if you have a setting where most servers do not have PQ certificates, then disabling the non-PQ certificates means that lots of servers can't do secure connections at all. This obviously causes a lot of breakage and, depending on the actual vulnerability of the non-PQ algorithms, might not be good for security either, especially if people fall back to insecure HTTP. See: https://educatedguesswork.org/posts/pq-emergency/ https://educatedguesswork.org/posts/pq-emergency/ and https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap https://www.chromium.org/Home/chromium-security/post-quantum... [0] The situation is worse for Apple.
    - FiloSottile 7mo ago
      Indeed, in an open system like the WebPKI it's fine in theory to only make the central authority PQ, but then you have the ecosystem adoption issue. In a closed system, you don't have the adoption issue, but the benefit to making only the central authority PQ is likely to be a lot smaller, because it might actually be the only authority. In both cases, you need to start moving now and gain little from trying to time the switchover.

layer8 7mo ago

> The only exception is when there would exist some digital documents that would completely replace some traditional paper documents that have legal significance, like some documents proving ownership of something, which would be digitally signed, so forging them in the future could be useful for somebody, in which case a future-proof signing method would make sense for them. This very much exists. In particular, the cryptographic timestamps that are supposed to protect against future tampering are themselves currently using RSA or EC.

ekr____ 7mo ago
Yes, though we do know how to solve this problem by using hash-based timestamping systems. See: https://link.springer.com/article/10.1007/BF00196791 https://link.springer.com/article/10.1007/BF00196791 Of course, the modern version of this is putting the timestamp and a hash of the signature on the blockchain.

Perseids 7mo ago

Super important: Don't replace traditional (elliptic curve) Diffie-Hellman with ML-KEM, but enhance it by using hybrid key exchanges. Done thusly, you need to break both the classical and post-quantum cryptography to launch an attack. If you worry about a >=1% risk of quantum attacks being available soon, you should also worry about a >=1% risk of the relatively new ML-KEM being broken soon. The risk profile is pretty comparable. For both cases there are credible expert opinions that say the risk is incredibly overrated and credible expert opinions that say the risk is incredible underrated. Filippo has linked opinions that quantum attacks are right around the corner. People like Dan Bernstein (djb) are throwing all their weight to stress that anything but hybrids are irresponsible. I don't think there is anybody that says "hybrids are a bad idea", just people that want to make it easy to choose non-hybrid ML-KEM.

pie_flavor 7mo ago
How do you mean the risk profile is comparable, when ECDH is nearly guaranteed to be broken in five years and Kyber is two decades old? The two have nothing to do with each other, the ECDH component of a hybrid becomes worthless before you next replace your smartphone, and bloating the protocol can only hurt adoption. Yes, djb keeps making the same crankish complaint without any evidence or reason, that doesn't mean you have to repeat it uncritically.
- littlestymaar 7mo ago
  > when ECDH is nearly guaranteed to be broken in five years Says who? There's a big difference between “we can't be sure that ECDH stays secure for five more years” and “ECDH is nearly guaranteed to be broken”. There has been two major papers in the beginning of the year that advanced the state of the art enough to question the prior assumption about the slowness of QC progress. Now we know that rapid advances are possible and we must take that into account in risk assessment. But that doesn't mean that rapid advances are guaranteed. Things could stay stagnant for 15 more years at this point before the next breakthrough. And if that's the case, then ECDH could very well remain relevant for the remaining century. We just cannot know if it happens, so we can't take the risk. But that doesn't mean that we are certain that the risk will materialize.