Re: [Cfrg] new authenticated encryption draft

David,

Can you point me to an existing randomized AEAD specification that
might have a more detailed rationale its randomness? I'm having a hard
time understanding why this is necessary. It seems to me that almost
any device on a network will have some sort of unique identifier
associated with it, e.g., a MAC or IP address. This could be used to
guarantee a unique nonce as input to the AEAD algorithm.

It seems to me that your specification allows two types of AEAD
schemes that aren't interchangeable:

1) The deterministic AEAD schemes, which accept as input a nonce, and
which have a redundant output--the IV.

2) The randomized AEAD schemes, which accept as input an "IV
contribution" (which may be reused), and which have an internal source
of randomness which is used to generate the IV, which is then returned
to the user.

I tend to think that the internal source of randomness required for
the second class of schemes will be extremely difficult to design in a
portable (between architectures) way. In fact, I can't think of any
crypto specifications at this level that assume, as part of the
specification, an internal source of randomness. Usually, the
randomness is a required input, not an output. How would GCM or EAX or
CCM be specified if the algorithms required an internal source of
randomness? They would have to reference a particular class of
certified hardware random number generators.

Personally--and this is only my opinion--I find it much cleaner to
separate the specifications of AEAD schemes and sources of randomness.
Let all AEAD schemes be specified to be deterministic, and to accept
at input a nonce. Let random number generation be handled in another
component, that may have to be more machine-specific. I'd like to hear
others' opinions on this.

-John

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg