4 ms·

> Secondly, flexibility is mentioned, but I think the last serval years have shown that flexibility is huge vulnerability in crypto systems. All the criticism

by 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.
- kibwen 2y ago
  Sure, but the same concern exists even for applications that have inflexible protocols. You either have someone willing and able to say that enough is enough and break backwards compatibility, or you don't.
  - tedunangst 2y ago
    Well, I think one of the problems with ssl3 is nobody really knew who was using it on purpose, and even the people using it didn't know. With something like WireGuard 2, you will presumably figure out pretty quickly which endpoints can't communicate if they're still on wg1. At least that's something.

by kibwen 2y ago

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.

kibwen 2y ago
Sure, but the same concern exists even for applications that have inflexible protocols. You either have someone willing and able to say that enough is enough and break backwards compatibility, or you don't.
- tedunangst 2y ago
  Well, I think one of the problems with ssl3 is nobody really knew who was using it on purpose, and even the people using it didn't know. With something like WireGuard 2, you will presumably figure out pretty quickly which endpoints can't communicate if they're still on wg1. At least that's something.