SHA1 collisions proven possisble

Keith Medcalf kmedcalf at dessus.com
Mon Feb 27 04:02:48 UTC 2017



On Sunday, 26 February, 2017 19:16 Matt Palmer <mpalmer at hezmatt.org> said:
> On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote:
> > On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote:
> > > I repeat something I've said a couple times in this thread: If I can
> > > somehow create two docs with the same hash, and somehow con someone
> > > into using one of them, chances are there are bigger problems than a
> > > SHA1 hash collision.
> > >
> > > If you assume I could somehow get Verisign to use a cert I created to
> > > match another cert with the same hash, why in the hell would that
> > > matter?  I HAVE THE ONE VERISIGN IS USING.  Game over.
> > >
> > > Valdis came up with a possible use of such documents. While I do not
> > > think there is zero utility in those instances, they are pretty small
> > > vectors compared to, say, having a root cert at a major CA.
> >
> > I want a google.com cert.  I ask a CA to sign my fake google.com
> > certificate.  They decline, because I can't prove I control google.com.
> 
> Even better: I want a CA cert.  I convince a CA to issue me a regular,
> end-entity cert for `example.com` (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...

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?








More information about the NANOG mailing list