2
$\begingroup$

There are articles floating around the topic of SHA-1 deprecation. The gist of it is that in (mostly) developing countries, people are still using mobile/computing devices that are 5 years old (or older) and do not support SHA-2. As a consequence, the deprecation of SHA-1 would result in their being "cut off from the Internet as we know it."

Yeah, there are many problems with this oversimplification, but here's some questions:

  1. There are estimates that it would cost something in the ballpark of several hundred thousand US dollars to create a SHA-1 collision. But how much time does that take?

  2. Depending on the answer to the first question, why not extend client and CA support for SHA-1, provided that certificate validity periods are simply shortened to 6 months? 3 months? One? This seems especially more feasible with the kind of automation LetsEncrypt offers.

In my view, there's nothing wrong with the SHA-1 algorithm. No one has "broken" or is coming close to "breaking" the algorithm per se. It is just becoming computationally more feasible to overcome its cryptographic strength over the typical course of a certificate's validity period. So long as that's the case, although it may be no longer well suited for year-long (or multi-year) certificate validity periods, it's still technically safe to use in more limited applications. After all... all forms of encryption are about time, not about impenetrability.

Would this proposal sufficiently eliminate known risks to make SHA-1 safe to use on older devices?

$\endgroup$
1
  • $\begingroup$ For every year that passes, you can assume the amount of time it takes to forge a cert will be reduced to half, 2 years a quarter, and so forth. Take that into account $\endgroup$ Dec 16, 2015 at 21:24

1 Answer 1

3
$\begingroup$

The short answer is that no, the length of validity would not help in a major way.

First you have to consider how the attack on the collision resistance of SHA-1 applies to certificates. The idea, and how it actually worked in the case of MD5, is basically:

  1. Attacker finds a collision in the hash function that generates two certificates with the same hash.
  2. They give1 the innocent one to a CA for signing.
  3. Now they also have a signature for the malicious one, that e.g. allows them to claim to be Google.

A validity period of months would still allow them to make use of it for months. That may be less of a return for the attacker's resources than using it for years, but you would expect such an attack to eventually be exposed anyway. And if, like poncho mentions in the comment, the attacker can generate a malicious certificate with a different period of validity, then even that is not an issue.

Now, if you think that in the next year or so no-one will be able to generate a collision due to the expense or time it takes, then you can argue that certificates should be allowed for an extra year. However, the validity period itself does not really matter in this case.


1 Actually, the CA typically generates the certificate and the attacker must predict how and choose the information they give.

$\endgroup$
5
  • 2
    $\begingroup$ Actually, if the attacker can control the validity time in the malicious cert, there's no reason why they have to give the same time interval that the innocent cert has; it can have a much longer validity time. $\endgroup$
    – poncho
    Dec 16, 2015 at 21:35
  • 1
    $\begingroup$ @poncho, good point, though I suppose that could be checked for by the client... but not by those devices that cannot be updated. $\endgroup$
    – otus
    Dec 16, 2015 at 21:38
  • 2
    $\begingroup$ if those devices could be updated, they could be modified to handle SHA-2 certs... $\endgroup$
    – poncho
    Dec 16, 2015 at 21:42
  • $\begingroup$ @poncho, exactly. $\endgroup$
    – otus
    Dec 16, 2015 at 21:43
  • 2
    $\begingroup$ @poncho make the issuer cert also short-lived. An EE issuer should always be an intermediate, and here almost certainly a dedicated new one, something roughly like "Vemody class negative limited temporary compatibility server CA G1512, CPS hxxp://0.0.0.0/not-actually-secure ". $\endgroup$ Dec 17, 2015 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.