Re: [Cfrg] new authenticated encryption draft

[David McGrew <[e-mail]>]

Hi John,

On Sep 14, 2006, at 6:37 PM, John Wilkinson wrote:

> David,
>
> Can you point me to an existing randomized AEAD specification that
> might have a more detailed rationale its randomness?

EAX, for one.  It was an explicit design goal for that mode.

It is an aim for the AEAD draft to be useful in scenarios in which a  
secret key is stored over a long term, including challenge/response  
applications that use random nonces rather than sequence numbers for  
anti-replay protection.  Let me turn your question around: can you  
point me to an existing C/R protocol that uses unique IVs rather than  
random IVs?

> 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.
>

Most network identifiers are not suitable for use in constructing  
nonces.  For example, IP addresses are not suitable because of  
network address translation (NAT) and DHCP, besides the fact that the  
address identifies an interface rather than a device.  Using a  
network identifier would also put part of the IV under the control of  
a system which may not provide high assurance about the distinctness  
of the IVs, which is not always acceptable.

> 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.

The DSA and ECDSA signature algorithms require an internal random  
source.	

> 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.

Why?

David

>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg