4 ms·

Algorithm agility has been a hilarious disaster for designing secure systems. In reality even protocols like TLS that are nominally agile advance primarily by v

Algorithm agility has been a hilarious disaster for designing secure systems. In reality even protocols like TLS that are nominally agile advance primarily by versioning, not agility - and TLS is somewhat of a best case here compared to e.g. the mess of JOSE.

tptacek 7y ago
You're more right than the parent comment --- algorithm agility is, I believe, an increasingly discredited idea among cryptography engineers --- but there's truth to the idea that a serious PQC scheme is going to be paired with a conventional key exchange, so that a new lattice crypto attack won't break the whole handshake. That's not "agility" --- the schemes will almost certainly be hermetically sealed, one PQC KEX and one curve KEX --- but it does mean you can deploy PQC now without compromising your whole cryptosystem. The big issue here is that this observation doesn't break the premise of the article. It remains true that we don't know enough about how real-world quantum computers, if they ever exist at scales useful to attack cryptography, will work.
stouset 7y ago
This was the reply I came here to write.
throw0101a 7y ago
> In reality even protocols like TLS that are nominally agile advance primarily by versioning, not agility In the last ten years we've been able to disable CBC-based ciphers to protect against POODLE and BEAST, and disable RC4 to protect against Bar-mitzvah and NOMORE, all the while a legacy device could stick with TLS 1.0 without any code changes. All that was necessary was to tweak the cipher preferences. Being able to support both AES and ChaCha20 is a good thing, and when AESng/Mambo40 come along it will be easier to add them to the protocol in a rolling fashion IMHO.
- morelisp 7y ago
  If that TLS 1.0 device had never needed to support RC4 in TLS to begin with, which practically speaking it never really needed to, we could've done less work at implementation time, provided clearer guidance to users when the vulnerabilities were discovered, and likely had fewer affected users to begin with.
  - throw0101a 7y ago
    > If that TLS 1.0 device had never needed to support RC4 in TLS to begin with, which practically speaking it never really needed to ... Except that we did not know about not needing to. When BEAST came out a lot of recommendations said to switch over to RC4: * https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST...

tptacek 7y ago

You're more right than the parent comment --- algorithm agility is, I believe, an increasingly discredited idea among cryptography engineers --- but there's truth to the idea that a serious PQC scheme is going to be paired with a conventional key exchange, so that a new lattice crypto attack won't break the whole handshake. That's not "agility" --- the schemes will almost certainly be hermetically sealed, one PQC KEX and one curve KEX --- but it does mean you can deploy PQC now without compromising your whole cryptosystem. The big issue here is that this observation doesn't break the premise of the article. It remains true that we don't know enough about how real-world quantum computers, if they ever exist at scales useful to attack cryptography, will work.

stouset 7y ago

This was the reply I came here to write.

throw0101a 7y ago

> In reality even protocols like TLS that are nominally agile advance primarily by versioning, not agility In the last ten years we've been able to disable CBC-based ciphers to protect against POODLE and BEAST, and disable RC4 to protect against Bar-mitzvah and NOMORE, all the while a legacy device could stick with TLS 1.0 without any code changes. All that was necessary was to tweak the cipher preferences. Being able to support both AES and ChaCha20 is a good thing, and when AESng/Mambo40 come along it will be easier to add them to the protocol in a rolling fashion IMHO.

morelisp 7y ago
If that TLS 1.0 device had never needed to support RC4 in TLS to begin with, which practically speaking it never really needed to, we could've done less work at implementation time, provided clearer guidance to users when the vulnerabilities were discovered, and likely had fewer affected users to begin with.
- throw0101a 7y ago
  > If that TLS 1.0 device had never needed to support RC4 in TLS to begin with, which practically speaking it never really needed to ... Except that we did not know about not needing to. When BEAST came out a lot of recommendations said to switch over to RC4: * https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST...