Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:02 ADT
Lewis McCarthy (lmccarth@cs.umass.edu)
Wed, 01 Jul 1998 00:13:45 -0400
bram writes regarding RFC 2104:
> That RFC says the following:
>
> > We recommend that the output length t be not less than half the length
> > of the hash output (to match the birthday attack bound)
>
> Which is completely reasonable. It then goes on to say the following:
>
> > These properties, and actually stronger ones, are commonly assumed for
> > hash functions of the kind used with HMAC.
>
> Notice the word 'assume'. Cryptographers aren't normally in the business
> of assuming.
I'm not sure what point you were making here. Cryptographers commonly
make assumptions about, say, the hardness of the DL problem or of the
integer factorization problem. These assumptions are still fair game
for researchers who wish to test their validity. Meanwhile people
propose and build systems whose security rests on such widely
accepted, but unproven, assumptions.
> It then says:
>
> > In particular, a hash function for which the above properties do not
> > hold would become unsuitable for most (probably, all) cryptographic
> > applications
>
> This is completely untrue, given my trivial counterexamples above.
No. You've quoted a couple of sentences of RFC 2104 out of context.
To put them back into context, the first two paragraphs of Section 6 are:
> 6. Security
>
> The security of the message authentication mechanism presented here
> depends on cryptographic properties of the hash function H: the
> resistance to collision finding (limited to the case where the
> initial value is secret and random, and where the output of the
> function is not explicitly available to the attacker), and the
> message authentication property of the compression function of H when
> applied to single blocks (in HMAC these blocks are partially unknown
> to an attacker as they contain the result of the inner H computation
> and, in particular, cannot be fully chosen by the attacker).
>
> These properties, and actually stronger ones, are commonly assumed
> for hash functions of the kind used with HMAC. In particular, a hash
> function for which the above properties do not hold would become
> unsuitable for most (probably, all) cryptographic applications,
> including alternative message authentication schemes based on such
> functions. (For a complete analysis and rationale of the HMAC
> function the reader is referred to [BCK1].)
>
"These properties" in the second paragraph refers to the properties
stated in the first paragraph: collision resistance of the underlying
hash function (in a special case) and a property of the compression
function of the underlying hash. The phrase doesn't refer to anything
involving truncation of hash results.
-Lewis
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:02 ADT