Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 11 May 2010 13:08:33 -0500 (GMT-05:00)

David and all,

  good points here.  However the consideration of 
continuing the use of SHA-1 is IMO ill advised.  Further
SHA-2 due to key sizes now in question, is also IMO
ill advised.  FNV is fine, but not perfered.  

-----Original Message-----
>From: "Kemp, David P." <[email-masked]>
>Sent: May 11, 2010 12:38 PM
>To: [email-masked]
>Subject: Re: [TLS] Collisions (Re:  Consensus Call: FNV vs SHA1)
>
>In general, protocols and standardized data structures may make use of
>non-cryptographic hash functions in cases where collisions are
>anticipated and well-handled: i.e. as optimizations (optional) rather
>than as integrity (required) mechanisms.  PKIX AKI/SKI is an example:
>
>   "The authority key identifier extension provides a means of
>   identifying the public key corresponding to the private key 
>   used to sign a CRL. ... This extension is especially useful
>   where an issuer has more than one signing key, either due to
>   multiple concurrent key pairs or due to changeover."
>
>PKIX suggests two SHA-1 -based methods of generating SKIs (including the
>4 bit constant 0100 followed by the 60 least significant bits of the
>SHA-1 hash of a public key), and says "Other methods of generating
>unique numbers are also acceptable."
>
>The same reflexive "broken algorithm" evaluation concerns may exist for
>this use of SHA-1, and FNV would perform the function just as well
>without raising any eyebrows.
>
>If a collision did occur, an implementation would have to do an extra
>signature validation if it first picked the wrong certificate to
>validate a signature.  Not much of a penalty, and one which would have
>to be handled anyway for the case where AKI/SKI is not populated at all.
>
>Dave
>
>
>
>----- Nico wrote: ----
>
>Aside from that, I think FNV is a great hash function.  Its place will
>typically not be in Internet protocols, but in implementations.
>
>[*] I _can_ think of non-cryptographic uses of hash functions in
>    Internet protocols, starting with the use we made in GS2.  But in
>    general I think we'll want to review such uses carefully.  In the
>    case of GS2 it saved us the bother of creating a registry of SASL
>    mechanism names for GSS-API mechanisms.  Here the hash is used to
>    identify cached items, which seems fine provided that collisions are
>    well-handled.  In the GS2 case we decided that collisions were not a
>    problem for us (after all, we could always assign new OIDs to GSS
>    mechanisms that collide).
>
>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827