Re: The Poly1305-AES message-authentication code

From: David Wagner (daw_at_taverner.cs.berkeley.edu)
Date: 11/06/04 

Date: Sat, 6 Nov 2004 06:29:28 +0000 (UTC)

D. J. Bernstein wrote:
>In the Diffie-Hellman system, when two users have long-term public keys
>g^a and g^b, they immediately acquire a long-term shared secret g^ab at
>extremely low cost. This shared secret can then be used as a key to
>protect a huge volume of communication between those two users.

It can be, but it should not be. If you use that shared secret for every
message, it creates a risk that the shared secret could be leaked or
compromised in some way. Perhaps it is leaked because of a side channel.
Perhaps it is leaked because the administrator had access to it and
wrote it down on a piece of paper. Perhaps it is leaked because it
got written out to swap, and the contents of the swap space were later
revealed to the attacker. Who knows how it could happen?

If you want to take the risk that compromise of a single MAC key
compromises a huge volume of communications, you can do so. I prefer
not to take such risks, and therefore I prefer to use session keys that
are short-lived. (I also tend to prefer key exchange protocols with
forward secrecy; I prefer to zeroize session keys after they are no
longer needed; and so on.)

Granted, the use of session keys is probably much more important for
confidentiality (encryption) than for integrity (MACs). But I think it
is still a good idea even for a MAC, for reasons that have nothing to do
with the security of the MAC. I would change session keys often even if
I had full confidence in the ability of my MAC to remain secure for many,
many messages.

I guess I'm repeating myself and don't have anything new to add.
I apologize for the repetition.

>A variant of HMAC-MD5, namely HMAC-MD5(MD5(k,n),m)

Again, just to be clear: This is a strawman. You are the only person
proposing to use this. I am not proposing to use this method of deriving
session keys. I prefer other, more robust methods of deriving and
communicating session keys.

>Now, you've made a religious assertion that the long-term secret key
>should be used only in certain ways.

It is not religion; it is engineering. I have given the reasons for
those engineering choices.

>You haven't explained what those
>ways are, but you've made clear that your religion rejects HMAC-MD5 and
>Poly1305-AES---and, therefore, AES itself---while accepting variants
>such as HMAC-MD5(SHA(k,n),m) and AES(SHA(k,n),...).

I don't reject HMAC-MD5 or Poly1305-AES; on the contrary, I embrace
using them. I merely suggest that one use them as part of a larger
system that changes session keys every so often.

I don't accept HMAC-MD5(SHA(k,n),m). I don't see SHA(k,n) as a good
way of deriving session keys, and I would not recommend it. I am not
suggesting this construction, and I am not sure where it came from.

>Your religion is out of whack with the standard definitions of
>cryptographic security.

What do definitions (say, of a secure MAC functionality) have to do
with it? I'm talking about how to engineer a real system. Standard
definitions aren't trying to tell you how to build a system. The usual
definitions are aimed at measuring the security of a *primitive*, but no
one mistakes that for the question of how to use that primitive properly
in a larger system.

To be somewhat flip about it: It sounds like you're talking about
mathematics, while I'm talking about engineering. Both modes of thought
have their place.

Quantcast