Subject: Re: [Cfrg] new authenticated encryption draft

From: David McGrew <[email-masked]>
Date: Wed, 11 Oct 2006 15:20:11 -0700

Hi John,

On Sep 30, 2006, at 2:58 PM, John Wilkinson wrote:

> David,
>
> Sorry for my delayed response. I've been on business travel lately. I
> think you've got a lot of good comments from other people, and I we
> understand each others' positions, so I'll wrap up here.
>
> On 9/15/06, David McGrew <[email-masked]> wrote:
>> 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.
>
> I believe that EAX would be classified as "deterministic" under your
> terms, not as "random". EAX takes a nonce, message, and header, and
> deterministically produces a ciphertext (which includes both the
> unencrypted header and authentication tag). Given the same inputs
> (including nonce), EAX always produces the same ciphertext. Prof.
> Wagner, would you like to chime in here?
>

You're right about EAX.  What I meant is that it was a goal that EAX  
*could* be used with random nonces, though as you point out it is  
deterministic (and is intended for use with deterministic nonces).

>> 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.
>
> True, IP addresses may not always be useful in constructing nonces,
> but unique device serial numbers may be.
>
>> The DSA and ECDSA signature algorithms require an internal random
>> source.
>
> Yes, but they don't specify how to obtain that randomness.

Ah, I understand your point.

> From
> Appendix 3 of FIPS:
>
> "In the algorithms in sections 3.1 and 3.2, a secret b-bit seed-key  
> is used."
>
> The algorithms in sections 3.1 and 3.2 then specify how to use SHA to
> "stretch" an initial b-bit seed-key into infinitely many secret bits
> for generating private keys and signing.
>
> If you can guarantee a device has a unique b-bit key, I don't
> understand why you can't guarantee that it has a unique serial number.
>
> In any event, good job on writing something up for the lazier among us
> to throw darts at. :)
>

Thanks for bearing with me through the whole discussion!  :-)

David

> -John
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/cfrg

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

---

From: David McGrew <[email-masked]>
Date: Wed, 18 Oct 2006 06:52:00 -0700

Hi David and others,

I'm revisiting an old topic: AES-based key derivation.  It has come  
up in the EMU WG recently, as well as cropping up in the AEAD  
discussion.

On Aug 29, 2006, at 10:22 AM, David Wagner wrote:

> David McGrew  wrote:
>> AFAIK there is no
>> FIPS-140 approved method for deriving an encryption key and a MAC key
>> from a single key using AES.
>
> Well, I would use CMAC for that task.  CMAC is a NIST-approved mode.
> If AES is secure, then AES-CMAC is a secure PRF.  And any secure  
> PRF is
> perfectly fine for deriving an encryption key and a MAC key.
>

It belatedly occurs to me that CMAC, by itself, can't generate 192 or  
256 bit keys.  So we'd need to run CMAC in counter mode.  One way to  
do this is to augment Step 5 of the Concatenation HKDF Algorithm  
(Section 3.1.2 of http://www.ietf.org/internet-drafts/draft-dang- 
nistkdf-01.txt) from

              a. Compute Hash-i = H (counter || SV || algorithmID ||
             contextID {|| SharedInfo}).

to this

              a. Compute Hash-i = AES_CMAC(SV, counter || algorithmID ||
             contextID {|| SharedInfo}).

Comments welcome.  It is not clear to me that we really need to go to  
all the effort to define an AES-only way to derive secret keys from  
other secret keys, but if we do, this seems like a reasonable way to go.

Of course, the case of the authenticated encryption draft (the  
original thread), the contextID field would need to be set to a fixed  
value.  It would be superfluous, but it doesn't hurt to have it there.

David