[193842] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: SHA1 collisions proven possisble

daemon@ATHENA.MIT.EDU (Eitan Adler)
Mon Feb 27 01:25:53 2017

X-Original-To: nanog@nanog.org
In-Reply-To: <9989A639-F2F6-4FED-8FD9-9F648128530C@ianai.net>
From: Eitan Adler <lists@eitanadler.com>
Date: Sun, 26 Feb 2017 22:25:20 -0800
To: "Patrick W. Gilmore" <patrick@ianai.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org

On 26 February 2017 at 22:15, Patrick W. Gilmore <patrick@ianai.net> wrote:
> Composed on a virtual keyboard, please forgive typos.
>
> On Feb 26, 2017, at 21:16, Matt Palmer <mpalmer@hezmatt.org> wrote:
>>> 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` f=
or
>> the Basic Constraints extension.
>>
>> Wham!  I can now generate certs for *EVERYONE*.  At least until someone
>> notices and takes away my shiny new toy...
>
> Since I have said this somewhere on the order of half a dozen times, I wi=
ll assume I am missing something obvious and all of you are doing it right.
>
> So let me ask you: The attack creates two docs. You do not know the hash =
before the attack starts. You cannot take an existing file with a known has=
h and create a second file which matches the known hash. You start with not=
hing, run the "attack", and get two NEW docs that have the same hash. A has=
h which is brand new.
>
> Now, please explain how you take a cert with one hash and somehow use thi=
s attack, which creates two new docs with a new hash, to do, well, anything=
?

1. Create a certificate C[ert] for a single domain you control with hash h(=
c).
2. Create a second certificate A[ttack] marked as a certificate
authority such that h(C) =3D h(A).
3. Have a certificate authority sign cert C
4. Present the signature for A along with A for whatever nefarious
purpose you want.

See a similar version of this attack here using MD5 chosen-prefix
collision attack: https://www.win.tue.nl/hashclash/rogue-ca/



--=20
Eitan Adler

home help back first fref pref prev next nref lref last post