SHA1 collisions proven possisble

Matt Palmer mpalmer at
Mon Feb 27 07:58:14 UTC 2017

On Mon, Feb 27, 2017 at 01:15:28AM -0500, Patrick W. Gilmore wrote:
> On Feb 26, 2017, at 21:16, Matt Palmer <mpalmer at> wrote:
> > Even better: I want a CA cert.  I convince a CA to issue me a regular,
> > end-entity cert for `` (which I control) in such a way that I can
> > generate another cert with the same SHA1 hash, but which has `CA:TRUE` for
> > the Basic Constraints extension.
> > 
> > Wham!  I can now generate certs for *EVERYONE*.  At least until someone
> > notices and takes away my shiny new toy...
> In the example above, the CA knows the SHA-1 hash of the cert it issued.
> (We are assuming there is a CA which still does SHA-1.) How do you get
> that CA to believe the two OTHER certs with DIFFERENT hashes you have to
> create so you can have two docs with the same hash?

This is doable because the data that goes into the cert is mostly
predictable (or attacker controlled).  The public key is provided by the
attacker; the subject and sAN extension is attacker-provided, and a lot of
the rest is predictable (issuer, policy OIDs, etc etc).  Even the notBefore
and notAfter fields are, to some degree, predictable; you can measure the
average issuance delay to figure out when you need to submit your CSR(s) to
get favourable timestamps, and many CAs "round" values, to make that easier. 
Thus, constructing a "dummy" TBSCertificate ("to-be-signed certificate") to
play with isn't difficult.

The mitigation to a chosen prefix attack (which is what this is) is to make
the serial number a random number.  The CA/Browser Forum Baseline
Requirements (the agreed-upon rules between CAs and browsers) say that you
need to put "at least 64 bits of randomness" into the serial number field,
which supposedly mitigates this.  Unfortunately, that isn't a property you
can easily determine by observation, and I'll bet dollars to donuts it isn't
audited, so whether that would stand up to a determined attacker is a
Rumsfeldian question..

- Matt

More information about the NANOG mailing list