Re: [Cfrg] new authenticated encryption draft

[David McGrew <[e-mail]>]

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

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