5 ms·

Schneier had a less breathless account a few days ago: https://www.schneier.com/blog/archives/2022/08/nists-post-quantum-cryptography-standards.html https://ww

Schneier had a less breathless account a few days ago: https://www.schneier.com/blog/archives/2022/08/nists-post-quantum-cryptography-standards.html https://www.schneier.com/blog/archives/2022/08/nists-post-qu...

nottorp 4y ago
Also, Schneier's site doesn't have me agree to tracking without any possibility of rejection ;)
tptacek 4y ago
He's wrong about the "cryptographic agility" stuff, at least the way he's framed it. But then, another place where I'd part company with him is about the urgency for getting PQC slotted into real-world systems.
- emn13 4y ago
  Why do you think he's wrong? He's essentially saying IT systems need to be designed with the expectation that cryptographic algorithms will be attacked and may need to be replaced, as I understand it.
  - tptacek 4y ago
    If by "crypto agility" one means "we should research diverse cryptographic primitives and constructions so that we can be ready if something we rely upon breaks", nobody disagrees with that. But that's not what Schneier means. What he says instead is that "it’s vital that our systems be able to easily swap in new algorithms when required". That approach has a virtually unbroken track record of failure. It demands negotiation, which introduces bugs, and even after you get past that, it doesn't work: you literally always end up with downgrade attacks (see, for instance, the DNSSEC work at Black Hat this year). Sometimes those downgrade attacks introduce vulnerabilities for parties that would never have even attempted to use the legacy crypto.
    - hnhuhn 4y ago
      I don't think that being able to easily swap to new algorithms means negotiation. Signal e.g. can easily switch to other encryption schemes, just as Whatsapp shipped e2ee in a few weeks. After some time, you are forced to upgrade the app in order to be able to use it.
    - michaelt 4y ago
      Doesn't every major cryptosystem have multiple ciphersuites, though? There's things like SSL, SSH and GPG, truecrypt, bitlocker, /etc/passwd, ntpsec - even git is trying to upgrade their hashes from SHA1 to something longer. There are only a handful of exceptions, like TOTP. Isn't it a must-have feature? Or has the feature become less important than it was 25 years ago when those protocols were being designed?
      - tptacek 4y ago
        Yes, and every one of those major cryptosystems has been a debacle, in large part because of the negotiations imposed by ciphersuites. It is not a must-have feature; it's a feature cryptography engineering best practice is rapidly beginning to recognize as an anti-feature. See WireGuard for an example of the alternative: you version the whole protocol, and if some primitive you depend on has a break, you roll out a new version --- which, historically, you've effectively had to do anyways in legacy protocols.
        Zamicol 4y ago
        Cryptographic agility means to support multiple cryptographic primitives and to not be overly coupled to a single primitive. WireGuard is a great example of a product with cryptographic agility. https://www.wireguard.com/protocol https://www.wireguard.com/protocol Cryptographic agility says nothing about "version the whole protocol".
        tptacek 4y ago
        No, it's pretty widely recognized that WireGuard is in a sense a repudiation of "agility". You can look at, for instance, the INRIA analysis/proof paper to see how a bunch of disinterested cryptographers describe it: "many new secure channel protocols eschew standardisation in favour of a lean design that uses only modern cryptography and supports minimal cryptographic agility." If you want to say "minimalist agility is good and you're just saying maximalist agility is bad", that's fine, we're just bickering about terms. But that's pretty obviously not what Schneier is talking about.
  - deleted 4y ago
    [deleted]
  - fortenforge 4y ago
    Further reading on this subject: https://www.imperialviolet.org/2016/05/16/agility.html https://www.imperialviolet.org/2016/05/16/agility.html
Zamicol 4y ago
I think this is the link: https://www.schneier.com/blog/archives/2022/08/sike-broken.html https://www.schneier.com/blog/archives/2022/08/sike-broken.h...

nottorp 4y ago

Also, Schneier's site doesn't have me agree to tracking without any possibility of rejection ;)

tptacek 4y ago

He's wrong about the "cryptographic agility" stuff, at least the way he's framed it. But then, another place where I'd part company with him is about the urgency for getting PQC slotted into real-world systems.

emn13 4y ago
Why do you think he's wrong? He's essentially saying IT systems need to be designed with the expectation that cryptographic algorithms will be attacked and may need to be replaced, as I understand it.
- tptacek 4y ago
  If by "crypto agility" one means "we should research diverse cryptographic primitives and constructions so that we can be ready if something we rely upon breaks", nobody disagrees with that. But that's not what Schneier means. What he says instead is that "it’s vital that our systems be able to easily swap in new algorithms when required". That approach has a virtually unbroken track record of failure. It demands negotiation, which introduces bugs, and even after you get past that, it doesn't work: you literally always end up with downgrade attacks (see, for instance, the DNSSEC work at Black Hat this year). Sometimes those downgrade attacks introduce vulnerabilities for parties that would never have even attempted to use the legacy crypto.
  - hnhuhn 4y ago
    I don't think that being able to easily swap to new algorithms means negotiation. Signal e.g. can easily switch to other encryption schemes, just as Whatsapp shipped e2ee in a few weeks. After some time, you are forced to upgrade the app in order to be able to use it.
  - michaelt 4y ago
    Doesn't every major cryptosystem have multiple ciphersuites, though? There's things like SSL, SSH and GPG, truecrypt, bitlocker, /etc/passwd, ntpsec - even git is trying to upgrade their hashes from SHA1 to something longer. There are only a handful of exceptions, like TOTP. Isn't it a must-have feature? Or has the feature become less important than it was 25 years ago when those protocols were being designed?
    - tptacek 4y ago
      Yes, and every one of those major cryptosystems has been a debacle, in large part because of the negotiations imposed by ciphersuites. It is not a must-have feature; it's a feature cryptography engineering best practice is rapidly beginning to recognize as an anti-feature. See WireGuard for an example of the alternative: you version the whole protocol, and if some primitive you depend on has a break, you roll out a new version --- which, historically, you've effectively had to do anyways in legacy protocols.
      - Zamicol 4y ago
        Cryptographic agility means to support multiple cryptographic primitives and to not be overly coupled to a single primitive. WireGuard is a great example of a product with cryptographic agility. https://www.wireguard.com/protocol https://www.wireguard.com/protocol Cryptographic agility says nothing about "version the whole protocol".
        tptacek 4y ago
        No, it's pretty widely recognized that WireGuard is in a sense a repudiation of "agility". You can look at, for instance, the INRIA analysis/proof paper to see how a bunch of disinterested cryptographers describe it: "many new secure channel protocols eschew standardisation in favour of a lean design that uses only modern cryptography and supports minimal cryptographic agility." If you want to say "minimalist agility is good and you're just saying maximalist agility is bad", that's fine, we're just bickering about terms. But that's pretty obviously not what Schneier is talking about.
- deleted 4y ago
  [deleted]
- fortenforge 4y ago
  Further reading on this subject: https://www.imperialviolet.org/2016/05/16/agility.html https://www.imperialviolet.org/2016/05/16/agility.html

Zamicol 4y ago

I think this is the link: https://www.schneier.com/blog/archives/2022/08/sike-broken.html https://www.schneier.com/blog/archives/2022/08/sike-broken.h...