Robert Sparks <rjsparks at estacado.net> writes:
So, I read this to say the proposed recommendation of CRC32 as
specified in rfc3309 is ok to go forward with.
I think this is fine.
Based on the discussion, I think I will also point out that MD5 can
be used (and has been used in the past),
that its use would rely only on its collision properties, not any
cryptographic properties, and point out that it
is much slower than the alternative above.
Any objection?
No to the choice of CRC32, but yes to the language you suggest
above. Collision-resistance is a technical term in cryptography,
the text above is quite confusing.
Informally, the property you want is that two hashes of the
input values have a 2^(-b) chance of having the same hash
value. Formalizing this turns out to be a really knotty problem
especially if you assume (as is true in this case) that the
input strings are non-uniform. (universal hashing is one
way around this problem).
Anyway, I think the correct language ought to be something
like this:
A common way to create the second part of the branch parameter
value when forking a request is to compute a hash over the
concatenation of the Request-URI, any Route header field values
used during processing the request and any other values used by the
location service logic while processing this request. The hash
should be chosen so that there is a low probability that two
distinct sets of these parameters will collide. Because the maximum
number of messages which need to be compared is 70 [is this right],
the chance of a collision is low even with a relatively small hash
value, such as 32 bits. CRC-32 [REF] is a specific acceptable
function, as is MD5 [REF]. Note that MD5 is being chosen purely
for non-cryptographic properties. An attacker who can control the
inputs in order to produce a hash collision can attack the
connection in a variety of other ways.
-Ekr