[tptacek]

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.

[michaelt]

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]

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.

[est31]

If you have multiple WireGuard versions, in a migration setting, you also need to do some negotiation at the start, no? Wouldn't that be potentially vulnerable to downgrade attacks as well?

[tptacek]

No: you simply don't speak the old versions.

[est31]

So the migration looks like "upgrade the client or you won't be able to connect to the server any more"? What if you use the client to talk to multiple servers, some that use the old version, some that use the new version? Maybe via a config variable adjustable per server? Then you do out of band version negotiation, and you might get away with this in the VPN setting, where entering arcane config vars is commonplace, but not in e.g. the TLS setting.

[some_furry]

I wrote a lot about a similar debate recently, but in the context of encryption at rest rather than encryption in transit

https://soatok.blog/2022/08/18/burning-trust-at-the-quantum-...

For brevity, start reading at "Isn’t cryptography fun?" which contains the relevant portion.

[tptacek]

Entering arcane config variables is extremely not commonplace with WireGuard.

[Zamicol]

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

Cryptographic agility says nothing about "version the whole protocol".

[tptacek]

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.

[Zamicol]

All the works I've read of Schneier have given me the impression of the above definition, "support multiple cryptographic primitives and do not be overly coupled to a single primitive."

Serendipitously, I just tweeted about this 11 days ago: https://twitter.com/CyphrMe/status/1556660870901403648

"The moral is the need for cryptographic agility. It’s not enough to implement a single standard; it’s vital that our systems be able to easily swap in new algorithms when required."

Do you have a link to something that in your mind represents what Schneier is talking about?

[tptacek]

A modern cryptosystem wouldn't be designed to swap in new algorithms; it would pick a single set of algorithms and constructions, and version the whole system. Which is how WireGuard works: you can't run AES WireGuard, or WireGuard with the standard P-curves.

[Spooky23]

Look at TLS/SSL. TLS 1.2 was out for years until public vulnerabilities forced deprecation of SSL 3 and TLS 1.0.

[emn13]

I see what you mean. I'm not seeing that in this particular article, but without getting sidetracked by whether he's said that before - I think there are two flavors of agility here.

You're arguing against runtime agility. That makes sense; in fact, the more runtime agility you have, the less design-time agility you have, because all that dynamic negotiation is quite the constraint - and as you point out, a source of flaws.

Even negotiation has flavors. Classic TLS tried to make supporting old ciphers "secure", but even negotiation in which you assume the attacker _can_ control the cipher can be useful - the point then being not to do so long-term, but merely as a technique to allow non-instantaneous roll-out world wide. There's a difference between trying to support but never use legacy stuff and also refusing to specify the current gold standard, and merely having a protocol that supports multiple ciphers only to the extent necessary to occasionally replace a single old configuration with a single new one.

I'm not sure whether there's a huge difference between merely supporting research diversity, and having non-runtime but design-time agility. Perhaps those are the same thing. I guess it gets interesting where encryption primitives aren't just ephemeral communication tools, but a more intrinsic part of the software (such as in signing, and especially in stuff like blockchains) - is there a way to have at least the option of swapping primitives without weakening the guarantees today?

In any case; thanks for the clarification!

[layer8]

To me, it just means that the formats shouldn’t be hardcoded to a single algorithm (e.g. like Git is to SHA-1), but should allow for different (including future) algorithms, like e.g. X.509 certificates do. I do work in the electronic signature space, where this is important, and there are no negotiation scenarios there.

[hnhuhn]

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.

[bawolff]

Well i agree generally, if we are talking about these new, basically experimental, post quantum algorithms, i feel like the balance shifts a bit since they are still so new (on the other hand maybe using them is just premature at this point)

[tptacek]

The universal answer to this concern is to run a conventional key exchange alongside the PQC key exchange.