3 ms·

> But even if a quantum computer is never built, new PQ standards are safer, more resilient, and more flexible than their classical counterparts. I disagree.

> But even if a quantum computer is never built, new PQ standards are safer, more resilient, and more flexible than their classical counterparts. I disagree. First of all they are far more inconvenient. They keynotes and signature sizes are bigger. With Curve25519 ECC we can have 256 bit keys. Secondly, flexibility is mentioned, but I think the last serval years have shown that flexibility is huge vulnerability in crypto systems. Finally, I feel pretty confident that the NSA doesn’t know too much more than we do about RSA or ECC which have been studied, studied, implemented, and analyzed for decades in the open. I worry with Post-Quantum algorithms, that there is a good chance that the NSA knows far more about them than does the public cryptography community.

setopt 2y ago
I guess we then have to bet… Is it more likely that NSA has a secret large-scale quantum computer, or that they have a secret vulnerability in post-quantum algorithms? And does it matter anyway if they have a secret backdoor in your OS :)
vlovich123 2y ago
Yeah I feel like the article glosses over the fact that PQ is not about crypto flexibility but specific crypto flexibility that is immune to a hypothetical QC and a lot is sacrificed to achieve that goal (namely signature sizes and/or in some cases performance). And no, you shouldn’t be using RSA but they completely gloss over that we have very very good ECC standards that in no way seem to be suffering the same problem as RSA (ie needing to regularly increase the key size) which is why afaict everyone has pretty much switched to ECC signatures unless they have some legacy reason.
kibwen 2y ago
> Secondly, flexibility is mentioned, but I think the last serval years have shown that flexibility is huge vulnerability in crypto systems. All the criticism of cryptographic agility that I have seen has involved an attacker negotiating a downgrade to a broken protocol. But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition. Being distrustful of untested post-quantum algorithms is fair. But you can always double-encrypt a message with both classical and post-quantum algorithms, which requires an attacker to break both of them in order to decipher it. This guards against both short-term algorithmic weaknesses in our nascent post-quantum algorithms, as well as long-term threats to classical algorithms from hypothetical quantum computers. Key sizes are larger, yes, but not show-stoppingly large; on par with secure RSA key sizes, which is tolerable. Kilobytes, not megabytes.
- CiPHPerCoder 2y ago
  > All the criticism of cryptographic agility that I have seen has involved an attacker negotiating a downgrade to a broken protocol. Consider this an additional data point, then: https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols https://paragonie.com/blog/2019/10/against-agility-in-crypto... In the years since I wrote that, several people have pointed out that "versioned protocols" are just a safe form of "crypto agility". However, when people say "crypto agility', they usually mean something like what JWT does. What JWT does is stupid, and has caused a lot of issues: https://www.howmanydayssinceajwtalgnonevuln.com/ https://www.howmanydayssinceajwtalgnonevuln.com/ If you want to use JWT securely, you have to go out of your way to do so: https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-library-if-you-absolutely-must/ https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l... > But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition. This makes sense in situations where you have versioned protocols :) This doesn't work if you're required to support RSA with PKCS1v1.5 padding until the heat death of the universe.
  - thadt 2y ago
    Hmmm, some recent protocols (thinking of MLS[1] here) have moved into a middle territory where they have a lot of options for piecing together a cryptographic suite, but then version that whole suite within the protocol. You can still change suites without changing the protocol, but it's not nearly as 'agile' as earlier suite and primitive negotiations. Maybe something more like "cryptographic mobility" instead of "agility"? You can carefully decamp and move from one suite (versioned protocol) to another without changing all your software, but you're not negotiating algorithms and semantics on the fly. [1] https://datatracker.ietf.org/doc/rfc9420 https://datatracker.ietf.org/doc/rfc9420
- tedunangst 2y ago
  The problem is that the broken protocol is frequently not removed. It is shoved to the end of the list, where it remains available, but that's "good enough" because surely it won't actually get used.

setopt 2y ago

I guess we then have to bet… Is it more likely that NSA has a secret large-scale quantum computer, or that they have a secret vulnerability in post-quantum algorithms? And does it matter anyway if they have a secret backdoor in your OS :)

vlovich123 2y ago

Yeah I feel like the article glosses over the fact that PQ is not about crypto flexibility but specific crypto flexibility that is immune to a hypothetical QC and a lot is sacrificed to achieve that goal (namely signature sizes and/or in some cases performance). And no, you shouldn’t be using RSA but they completely gloss over that we have very very good ECC standards that in no way seem to be suffering the same problem as RSA (ie needing to regularly increase the key size) which is why afaict everyone has pretty much switched to ECC signatures unless they have some legacy reason.

kibwen 2y ago

> Secondly, flexibility is mentioned, but I think the last serval years have shown that flexibility is huge vulnerability in crypto systems. All the criticism of cryptographic agility that I have seen has involved an attacker negotiating a downgrade to a broken protocol. But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition. Being distrustful of untested post-quantum algorithms is fair. But you can always double-encrypt a message with both classical and post-quantum algorithms, which requires an attacker to break both of them in order to decipher it. This guards against both short-term algorithmic weaknesses in our nascent post-quantum algorithms, as well as long-term threats to classical algorithms from hypothetical quantum computers. Key sizes are larger, yes, but not show-stoppingly large; on par with secure RSA key sizes, which is tolerable. Kilobytes, not megabytes.

CiPHPerCoder 2y ago
> All the criticism of cryptographic agility that I have seen has involved an attacker negotiating a downgrade to a broken protocol. Consider this an additional data point, then: https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols https://paragonie.com/blog/2019/10/against-agility-in-crypto... In the years since I wrote that, several people have pointed out that "versioned protocols" are just a safe form of "crypto agility". However, when people say "crypto agility', they usually mean something like what JWT does. What JWT does is stupid, and has caused a lot of issues: https://www.howmanydayssinceajwtalgnonevuln.com/ https://www.howmanydayssinceajwtalgnonevuln.com/ If you want to use JWT securely, you have to go out of your way to do so: https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-library-if-you-absolutely-must/ https://scottarc.blog/2023/09/06/how-to-write-a-secure-jwt-l... > But if the protocol is not yet broken, then being agile isn't a concern, and if/when the protocol does become broken, then you can remove support for the broken protocol, which is what you'd be forced to do anyway, so a flexible approach just seems like a more gradual way to achieve that future transition. This makes sense in situations where you have versioned protocols :) This doesn't work if you're required to support RSA with PKCS1v1.5 padding until the heat death of the universe.
- thadt 2y ago
  Hmmm, some recent protocols (thinking of MLS[1] here) have moved into a middle territory where they have a lot of options for piecing together a cryptographic suite, but then version that whole suite within the protocol. You can still change suites without changing the protocol, but it's not nearly as 'agile' as earlier suite and primitive negotiations. Maybe something more like "cryptographic mobility" instead of "agility"? You can carefully decamp and move from one suite (versioned protocol) to another without changing all your software, but you're not negotiating algorithms and semantics on the fly. [1] https://datatracker.ietf.org/doc/rfc9420 https://datatracker.ietf.org/doc/rfc9420
tedunangst 2y ago
The problem is that the broken protocol is frequently not removed. It is shoved to the end of the list, where it remains available, but that's "good enough" because surely it won't actually get used.