> First and most importantly, you have the chronology backwards

No, you and I are saying the same thing. Perhaps I worded it poorly? My point is they are fixating on a specific cipher they believe everyone should and will use. As it turns out, most are because Intel backed their choice and gave people incentive to utilize it.

Again, that would be the point of an encryption standard.

If fixating on a specific cipher is considered to be a standard, then let's deprecate it. I believe that was done in error. The standard should be around how each cipher is implemented in a secure manor, not limiting options to one cipher.

By diversifying options, brute force attempts get exponentially more expensive. It would be easy enough to list in CPU capabilities which instructions are supported.

None of this makes sense, sorry.

I think what LinuxBender may be trying to say is that if everyone standardizes down to a single cipher, that's not a good thing when that one cipher is shown to be a poor choice. It might be nicer if people have a few choices, so we have freedom to disable some of them when one becomes a poor choice.

Ex: when TLS clients and servers commonly supported 3DES, RC4, and AES, it wasn't universally painful to disable 3DES and RC4 (although if you support(ed) embedded clients without AES support, it's still painful). I think ChaCha looks to be a second good option that's gaining support.

I like ChaCha. I like AES. Systems should choose one or the other. Part of the point of ChaCha is to exploit the capabilities of general-purpose processors to get fast encryption without special-purpose hardware acceleration.

What people should not do is cascade ciphers, or, even worse, build systems that allow for cipher negotiation. Every system that negotiates has been a disaster.

If I were an intelligence agency or signal intelligence, I might argue for this so that I can narrow my attacks to one cipher. Perhaps the mafia or cartel would benefit from this. I can't imagine any other rational to argue for standardizing on a single cipher.

Interoperability. Limiting resources (hardware implementation for AES on chip, as opposed to hardware implementations for n ciphers).

Algorithm agility was once considered best practice and all but mandatory.

20+ years of issues with SSL and SSH, both in the standards and implementations, has taught us that the costs of supporting algorithm agility is much more than the gains. Borderline intolerable, in fact. Moreover, our two-decade track record of cryptanalysis and predictions of future breakthroughs has been very good.

We're much better able to predict the costs+benefits of a particular cryptographic primitive than we are of the protocols and software we build. If a cryptographic primitive is assessed as good enough, it's no longer considered desirable or even reasonable to hedge that assessment and permit substitution of the primitive during the lifetime of the protocol. The resultant complexity is much more likely to be the source of future problems than the primitive.

Sorry.