News for hackers. Stuff that matters.
Re:NIST advises services to not require that passwords be ch... by toast0 on Sunday May 21, 2017 @01:52AM (#14385891)
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.

Re:NIST advises services to not require that passwords be ch... by tptacek on Sunday May 21, 2017 @02:20AM (#14385948)
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.

Re:NIST advises services to not require that passwords be ch... by LinuxBender on Sunday May 21, 2017 @12:29PM (#14387954)
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.
Re:NIST advises services to not require that passwords be ch... by Tomte on Sunday May 21, 2017 @01:49PM (#14388263)
Interoperability. Limiting resources (hardware implementation for AES on chip, as opposed to hardware implementations for n ciphers).
Re:NIST advises services to not require that passwords be ch... by wahern on Monday May 22, 2017 @05:18PM (#14397013)
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.