Re: [TLS] Consensus Call: FNV vs SHA1

[Michael D'Errico <[e-mail]>]

With a birthday collision of 64 bits (thanks Dave for reminding me of
this), you would need about 6 million server certificates to achieve a
probability of 1 in a million that 2 of those 6 million certificates
hash to the same value.  Since servers change certificates about once
a year, and a client doesn't need to remember any hashes of expired
certificates, and there is no problem if the certificates of unrelated
servers collide, this seems to be a non-issue.

The only question is whether FNV is as good of a hash function as is
required to resist the birthday attack.  My simple test showed that it
might be, but IANAC and don't know how to determine that.

Mike



Nicolas Williams wrote:
> On Mon, May 10, 2010 at 10:39:28AM -0700, Joseph Salowey (jsalowey) wrote:
>> I don't see much new being added to this discussion at this point.  I'd
>> like to close on this.  If you have an opinion please indicate if:
>>
>> a) You favor SHA-1
>> b) You favor FNV-1a
> 
> Subsequent discussion shows that hash collisions are a problem for this
> protocol, though not a security problem.  As such I believe that (b) is
> now out of order, and therefore I now favor (a), with less or no
> truncation.
> 
> I believe additional text is required to explain what to do when
> collisions result, and also how to detect collisions (I think collisions
> can only be detected heuristically on handshake failure, but can
> confirmed on subsequent retry).
> 
> I believe too that a protocol design where collisions are avoided
> altogether is not desirable.  But something to consider might be to send
> not just a checksum/hash of cached objects, but also the name of the
> first cert in any cert/cert chain or other nameable object -- this would
> make collisions entirely avoidable by having operators check for them
> before installing new certs.
> 
> Nico