md2 hmac's
zelnaga
We assume H to be a cryptographic
hash function where data is hashed by iterating a basic compression
function on blocks of data. We denote by B the byte-length of
such
blocks (B=64 for all the above mentioned examples of hash
functions)
I assume it'd be 16 for MD2? To quote from <http://tools.ietf.org/
html/rfc1319>:
At this point the resulting message (after padding with bytes) has
a
length that is an exact multiple of 16 bytes. Let M[0 ... N-1]
denote
the bytes of the resulting message, where N is a multiple of 16.
That sure does make it sound like B=16 but confirmation would be
nice :)
Thomas Pornin
> I assume it'd be 16 for MD2?
Yes. But there is little reason to use MD2 nowadays: its security is
highly questionable, and it is awfully slow.
--Thomas Pornin
Tom St Denis
> According to zelnaga <zeln...@gmail.com>:
>
> > I assume it'd be 16 for MD2?
>
> Yes. But there is little reason to use MD2 nowadays: its security is
> highly questionable, and it is awfully slow.
>
> --Thomas Pornin
I thought it's still good as a PRF [in terms of security]. It is
horribly awfully ridiculously incredibly slow though. If you need a
16-byte MAC HMAC-MD5 should still be ok and it's plenty fast. You can
also just truncate the output of HMAC-SHA256 too...
Tom
Thomas Pornin
[about MD2]
> I thought it's still good as a PRF [in terms of security].
There are theoretical attacks, including a 2^97 preimage, which, while
not immediately applicable, is a concern (even MD4 fares better against
preimage attacks). Also, there are plenty of computable collisions on
the compression function, which is not a good sign.
--Thomas Pornin
Tom St Denis
Oh I don't disagree that MD2 is a bad hash, I'm just not aware of why
it would be insecure in the HMAC use case. That being said I'd avoid
MD2 on efficiency grounds anyways.
Tom