Re: [cryptography] Should Sha-1 be phased out?
On Tue, Oct 20, 2015 at 8:00 AM, Joachim Strömbergson wrote: > > Esp in embedded space, md5 is still very, very common even in new > designs. And SHA-1 is the new black. > > A typical setup is that someone has found out that there is a secure > hash function called md5 and decided to implement it in their new > system. When told that md5 is in fact broken since ages, the response is > usually a at the moment-decision that it is not used for security, and > that the application doesn't really have any security implications (i.e. > that the service performed by the system has no value). Yep. Actually the post-hoc rationalization is usually that collision-resistance isn't needed, only (2nd-)pre-image resistance. Some of the time this is actually true, but I think the people making the claim don't really know whether it is true. I think what they typically do is spend 60 seconds trying to imagine how they could attack their own system using collisions, and then having failed to find such an attack, they conclude that collision-resistance isn't needed for their system. Here's one of my favorite examples of this methodology, from Linus Torvald: http://git.vger.kernel.narkive.com/9lgv36un/zooko-zooko-com-revctrl-colliding-md5-hashes-of-human-meaningful#post2 So, my attempted contribution to this pattern was to help specify BLAKE2, so that instead of telling people "MD5 is broken! Switch to this secure but slower hash function!" we could tell them "MD5 is broken! Switch to this secure but faster hash function!" https://blake2.net/acns/slides.html It remains to be seen if they are any more responsive to the new argument than they have been for the last couple of decades to the old argument. Regards, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Should Sha-1 be phased out?
Aloha! ianG wrote: > On 15/10/2015 20:50 pm, Michael Kjörling wrote: >> On 14 Oct 2015 13:39 -0400, from kevinsisco61...@gmail.com (Kevin): >>> http://www.networkworld.com/article/2990801/sha-1-hashing-algorithm-could-succumb-to-75k-attack-researchers-say.html >>> >> >> To answer the question in the subject line: SHA-1 is already being >> phased out, particularly in areas where collision resistance matters. > > > In general, yes. Since around 2000 and the release of SHA2 family, SHA1 > has been a target for replacement for any collision weakness. How I wish that would be the truth. Esp in embedded space, md5 is still very, very common even in new designs. And SHA-1 is the new black. A typical setup is that someone has found out that there is a secure hash function called md5 and decided to implement it in their new system. When told that md5 is in fact broken since ages, the response is usually a at the moment-decision that it is not used for security, and that the application doesn't really have any security implications (i.e. that the service performed by the system has no value). Just like the war cry "use bcrypt!" we need to shout "kill md5!" over and over again until it reaches into the embedded dungeons. And then SHA-1. And RC4. And DES. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Should Sha-1 be phased out?
On 15/10/2015 20:50 pm, Michael Kjörling wrote: On 14 Oct 2015 13:39 -0400, from kevinsisco61...@gmail.com (Kevin): http://www.networkworld.com/article/2990801/sha-1-hashing-algorithm-could-succumb-to-75k-attack-researchers-say.html To answer the question in the subject line: SHA-1 is already being phased out, particularly in areas where collision resistance matters. In general, yes. Since around 2000 and the release of SHA2 family, SHA1 has been a target for replacement for any collision weakness. Just like MD5, there are still situations in which SHA-1 provides a fully adequate level of security even _if_ finding collisions was actually easy, and there are mitigative strategies that can be used to make finding useful collisions much harder (such as using multiple hash algorithms in tandem, or iterative hashing). A major use for even a cryptographic hash algorithm where collisions can be found reasonably easily is as a compression function for password hashing. With the above said, new designs that need collision resistance should obviously use more secure hash algorithms, and even more than that, should probably plan ahead for when _those_ algorithms reach the end of their useful life and allow for a migration strategy. SSL/TLS certificates allow for a migration strategy, which is why the fact that we no longer trust previously MD5 and now SHA-1 doesn't immediately break everything. For SHA-1 sunsetting, see for example [1], [2], both of which are over a year old. SHA-1 is on schedule to be sunset for TLS certificates at the end of 2016; the major browsers don't consider SHA-1 based certificates which are valid after 1 Jan 2017 to be trustworthy, which with the one-year commonly selected validity period of CA-signed certificates means we are only a few months away from starting to see this in practice. It's possible that this schedule is overly optimistic in light of recent events, but even so, that's moving SHA-1 from basically ubiquitous to actually untrusted in two and a half years, which is already quite fast. It would seem likely to me that accelerating the sunset of SHA-1 at this point would cause massive disruption, considering that people probably are making plans based on the announced dates. [1]: https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ [2]: https://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html Certificates are a basically horrible example, albeit quite truthful and full of perception. The basic problem of SHA1 in certificates is that it isn't or shouldn't be vulnerable to a collision attack. 1. Certificates are prepared in advance and should be unpredictable to the attacker. Following the old diktat of "never sign anything you didn't write yourself" certificates should have a nonce field in them. Since the attack on RapidSSL it has been required that certs should have that a nonce in them. They therefore should be invulnerable to collision attack. 2. One should be more concerned at high value targets. What this means is in short: sub-root certs and EV certs. It should be easy to prepare these more securely. Especially, cheap white end-user certs are not of particular value in the grand scheme of things. 3. In particular roots are not vulnerable to a collision attack at all. The signature on them could use ROT13 and it would still not be vulnerable to a collision attack. That's because the strength of the root comes from its manual placement in the root file, not from its signature. Indeed, the only reason it is delivered as a cert (and in this case a self-signed one) is because in the various x.509* things there isn't a standard for delivering a public key, nor a root list. Which is probably marketing more than engineering. That said, these nuances are too deep for the certificate bureaucracy and the buying public (devs) so we are seeing wholesale prejudice against any and all use of weaker message digests. This extends to browsers that reject perfectly safe root certificates because they use old message digests, and to libraries that try and deprecate the entire algorithm thus causing things like HMAC to stop working... Once the herd gets moving, it's a fearsome thing. It's a little like Adi Shamir's aphorism that only the simplest crypto survives: only the simplest security messages can be be sold. SHA1 is being buried, and if he'd only stop saying "I'm not dead yet" we could get on with the ceremony. The counter-strategy then is that when there comes a chance to refresh the crypto - use that opportunity. Replace the whole sodding lot with the latest stuff. That is, don't replace it with SHA2. Use SHA3. In 2025, the herd will be stampeding all over SHA256's tired old bones. You'll be grateful for having retired it in good time, and will have the space, peace and quiet to think about using SHA4. ian
Re: [cryptography] Should Sha-1 be phased out?
On 14 Oct 2015 13:39 -0400, from kevinsisco61...@gmail.com (Kevin): > http://www.networkworld.com/article/2990801/sha-1-hashing-algorithm-could-succumb-to-75k-attack-researchers-say.html To answer the question in the subject line: SHA-1 is already being phased out, particularly in areas where collision resistance matters. Just like MD5, there are still situations in which SHA-1 provides a fully adequate level of security even _if_ finding collisions was actually easy, and there are mitigative strategies that can be used to make finding useful collisions much harder (such as using multiple hash algorithms in tandem, or iterative hashing). A major use for even a cryptographic hash algorithm where collisions can be found reasonably easily is as a compression function for password hashing. With the above said, new designs that need collision resistance should obviously use more secure hash algorithms, and even more than that, should probably plan ahead for when _those_ algorithms reach the end of their useful life and allow for a migration strategy. SSL/TLS certificates allow for a migration strategy, which is why the fact that we no longer trust previously MD5 and now SHA-1 doesn't immediately break everything. For SHA-1 sunsetting, see for example [1], [2], both of which are over a year old. SHA-1 is on schedule to be sunset for TLS certificates at the end of 2016; the major browsers don't consider SHA-1 based certificates which are valid after 1 Jan 2017 to be trustworthy, which with the one-year commonly selected validity period of CA-signed certificates means we are only a few months away from starting to see this in practice. It's possible that this schedule is overly optimistic in light of recent events, but even so, that's moving SHA-1 from basically ubiquitous to actually untrusted in two and a half years, which is already quite fast. It would seem likely to me that accelerating the sunset of SHA-1 at this point would cause massive disruption, considering that people probably are making plans based on the announced dates. [1]: https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ [2]: https://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
