SHA1 collisions proven possisble

Tue Feb 28 19:16:23 UTC 2017

The CA signing the cert actually changes the fingerprint (and serial number, which is what is checked on revocation lists), so this is not a viable scenario. Beyond that, SHA1 signing of certificates has long been deprecated and no new public CAs will sign a CSR and cert with SHA1.

> On Feb 27, 2017, at 8:18 AM, Chris Adams <cma at cmadams.net> wrote:
> 
> Once upon a time, valdis.kletnieks at vt.edu <valdis.kletnieks at vt.edu> said:
>> There's only 2 certs.  You generate 2 certs with the same hash, and *then* get
>> the CA to sign one of them.
> 
> The point is that the signed cert you get back from the CA will have a
> different hash, and the things that they change that cause the hash to
> change are outside your control and prediction.
> 
> -- 
> Chris Adams <cma at cmadams.net>

Even with massive computing power, the tampering is still detectable since this attack does not allow for the creation of a hash collision from any arbitrary document. It requires specific manipulation of all items that result in a collision.

> On Feb 27, 2017, at 7:39 AM, valdis.kletnieks at vt.edu wrote:
> 
> On Mon, 27 Feb 2017 07:23:43 -0500, Jon Lewis said:
>> On Sun, 26 Feb 2017, Keith Medcalf wrote:
>> 
>>> So you would need 6000 years of computer time to compute the collision
>>> on the SHA1 signature, and how much additional time to compute the
>>> trapdoor (private) key, in order for the cert to be of any use?
>> 
>> 1) Wasn't the 6000 years estimate from an article >10 years ago?
>> Computers have gotten a bit faster.
> 
> No, Google's announcement last week said their POC took 6500 CPU-years
> for the first phase and 110 GPU-accelerated for the second phase.
> 
> You are totally on target on your second point.  A million node botnet
> reduces it to right around 60 hours.