[cryptography] Should Sha-1 be phased out?

ianG iang at iang.org
Sat Oct 17 06:37:22 EDT 2015


On 15/10/2015 20:50 pm, Michael Kjörling wrote:
> On 14 Oct 2015 13:39 -0400, from kevinsisco61784 at 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.



iang


More information about the cryptography mailing list