4 ms·

It certainly sounds like you're saying that cryptography needs to be brittle to be modern, which of course will find a lot of valid disagreement. There's no wa

It certainly sounds like you're saying that cryptography needs to be brittle to be modern, which of course will find a lot of valid disagreement. There's no way that any non-flexible cryptography can ever stay modern if it doesn't accommodate for various key sizes and algorithms. If for no other reason, because we continue to see more and more compute power that makes brute forcing smaller or weaker keys more feasible. Perhaps you can elaborate a bit more.

akerl_ 6y ago
The way to accommodate a new key size or algorithm is to say “v2 of the protocol will use $key_size and $cipher, and will not use $old_key_size or $old_cipher. Upgrade to this version due to $reason_old_setup_is_obsolete”. A casual observation of history will find that attempting to build negotiation of security features into a protocol is akin to opting in to a fun, optional class of major security vulnerability. For reference: SSL/TLS, GPG.
- amluto 6y ago
  Not necessarily. You can also tie algorithms to keys. For example, if you want to verify a signature, it’s perfectly reasonable for the public key to actually be (algorithm, private key as defined by that algorithm). What you don’t want to do is put the algorithm in a message that is potentially controlled by an attacker.
pvg 6y ago
The things you mention are causes of catastrophic security failures, not mitigations. 'Algorithm agility' (and related) is the source downgrade attacks, software that relies on cryptography tends to get broken computationally only after years of warnings about unsafe algorithms that are ignored, more often than not, due to over-reliance on standards both formal and de-facto.
user-the-name 6y ago
You will find disagreement only if you deliberately choose words like "brittle". The word you want is "simple". Crypto protocols need to be simple, to reduce attack surfaces. "Flexible" protocols are the ones that are actually "brittle" -this is where the use of metaphorical language breaks down. "Flexibility" actually just introduces more places to break. It is by now well accepted that modern crypto protocols should, in fact, be simple, and you will NOT find much disagreement with this.

akerl_ 6y ago

The way to accommodate a new key size or algorithm is to say “v2 of the protocol will use $key_size and $cipher, and will not use $old_key_size or $old_cipher. Upgrade to this version due to $reason_old_setup_is_obsolete”. A casual observation of history will find that attempting to build negotiation of security features into a protocol is akin to opting in to a fun, optional class of major security vulnerability. For reference: SSL/TLS, GPG.

amluto 6y ago
Not necessarily. You can also tie algorithms to keys. For example, if you want to verify a signature, it’s perfectly reasonable for the public key to actually be (algorithm, private key as defined by that algorithm). What you don’t want to do is put the algorithm in a message that is potentially controlled by an attacker.

pvg 6y ago

The things you mention are causes of catastrophic security failures, not mitigations. 'Algorithm agility' (and related) is the source downgrade attacks, software that relies on cryptography tends to get broken computationally only after years of warnings about unsafe algorithms that are ignored, more often than not, due to over-reliance on standards both formal and de-facto.

user-the-name 6y ago

You will find disagreement only if you deliberately choose words like "brittle". The word you want is "simple". Crypto protocols need to be simple, to reduce attack surfaces. "Flexible" protocols are the ones that are actually "brittle" -this is where the use of metaphorical language breaks down. "Flexibility" actually just introduces more places to break. It is by now well accepted that modern crypto protocols should, in fact, be simple, and you will NOT find much disagreement with this.