[cabfpub] A better way to do SHA-1 legacy

[Erwann Abalea]

There’s no need to collide SHA2 with this scheme.
The attacker can know in advance what the serial number will be; it may not be sequential, but is nevertheless predictable. So the attacker knows in advance what the final tbsCertificate will be. This is everything the attacker needs to mount a chosen-prefix collision.

Cordialement,
Erwann Abalea

Le 19 juil. 2016 à 16:22, Rob Stradling <rob.stradling at comodo.com<mailto:rob.stradling at comodo.com>> a écrit :

On 19/07/16 15:15, Erwann Abalea wrote:
There’s a disadvantage with this approach, in that now, there’s no random information inserted by the CA to raise the attack cost.
Back to chosen-prefix collision, from random-prefix collision.

With Phill's scheme, if you tweak some part of the TBSCertificate (e.g. the public key) in an attempt to find a collision, it affects the rigidly constructed serial number.

So you'd need to simultaneously collide SHA-1 and (at least 16 bytes of) SHA-2-512, right?

Is that any less hard than guessing "at least 64 bits of output from a CSPRNG" ?

Cordialement,
Erwann Abalea

Le 18 juil. 2016 à 19:36, philliph at comodo.com<mailto:philliph at comodo.com> a écrit :

Looking at the recent SHA-1 muck up, I am not confident that the current approach works. It fails for the same reason that random Elliptic Curve parameters fails, there is no mechanism that allows a process for generating random numbers to be audited.

So lets go to the solution we chose for EC - rigid construction. This can be made to be auditable.


I propose that the way be generate SHA-1 certs is as follows.

1) Generate the tbsCertificate with the Serial number field containing the bytes [0x01 … 0x01], minimum of 16 bytes. This is just a fixed value placeholder. Also add an extension OID for ‘phb-sha1-hack'

2) Generate the SHA-2-512 hash of the tbsCertificate structure

3) Truncate the result of (2) to the length of the desired Serial number and populate. The result is the final tbsCertificate value.


The advantage of this approach is that it is rigid and auditable. CertSentry can look for SHA-1 certs and check to see that the serial number format is compatible. If it is not compatible, the requisite consequences can be delivered to the guilty party automatically.

Yes, there are other ways to strengthen the process with commitments and such. But this approach guarantees that the cert has a work factor of 2^128 even if a second preimage attack on SHA-1 becomes feasible.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160719/42f264ac/attachment-0003.html>