Algorithm Agility?
tbray.org
Algorithm Agility?
1–10 of 22 posts
Re: Algorithm Agility?
#2Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arrangements, etc), and, most importantly, have required updates to the entire protocol anyways.
It's a bad idea and people shouldn't build it into new systems. Version the protocol instead, and plan on making it straightforward to upgrade the protocol and lock out old versions.
Re: Algorithm Agility?
#3Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…
Relevant Wikipedia article: https://en.wikipedia.org/wiki/Downgrade_attack
Re: Algorithm Agility?
#4Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…
And all of this is to say nothing of the frankly embarrassing problems that have plagued JWT as a result of algorithm agility (alg=none). Removing agility from JWT wouldn't make it a good specification, but it would certainly make it a better specification.
Re: Algorithm Agility?
#5Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…
I disagree with locking out old versions. It's a huge problem with older devices trying to access the web via SSL. I think it is important to consider device longevity and also the possibility of the user not being able to upgrade their software. Security is important, but it is not everything. There is also accessibility and compatibility to consider.
It's why I still test my websites with Netscape 3.x and keep http running.
Re: Algorithm Agility?
#6If someone suddenly breaks the stuff based on the 25519 curve there are going to be a lot of very unhappy people. I am still waiting for an explanation of why this particular curve is immune to such a breakthrough.
Re: Algorithm Agility?
#7> should developers just blast the key-bits into base64 and ship that?
I would argue given the key lengths of ed25519, not even to do base64, but just do hex encoding.
Sure it is a little longer, but in return you get much simpler encoding and decoding, no worries about flavors of base64 or padding.
In addition, hex encoding is much easier to verbally communicate to someone versus base64.
In a security context, I think making things as simple as possible has big benefits.
Re: Algorithm Agility?
#8Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…
It’d be nice to have someone summarize the discussion on crypto agility, which I think started with agl’s post on the subject. And recently filippo started a similar convo on twitter: https://twitter.com/filosottile/status/1386751406758105089?s...
I don’t think it’s just a crypto thing, agility is an issue in protocols that need to remain compatible in general.
Re: Algorithm Agility?
#9Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…
I disagree with locking out old versions. It's a huge problem with older devices trying to access the web via SSL. I think it is important to consider device longevity and also the possibility of the user not being able to upgrade their software. Security is important, but it is not everything. There is also accessibility and compatibility to consider. It's why I still test my websites with Netscape 3.x and keep http…
Can Netscape even work on modern Windows?
Re: Algorithm Agility?
#10Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…
Kerberos/AD is another example of this kind of mess. It has both LDAP and LDAPS not to mention the zoo of encryption types available for keytabs and credential caches. You can still use unsalted encryption types and DES!
While on one hand insecure LDAP is convenient for testing, I do think it should really just be removed and require LDAPS.