Re: [Cfrg] New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt

[David Jacobson <[e-mail]>]

On 2/14/14 3:44 AM, David McGrew wrote:
> Hi David,
>
> On 02/14/2014 01:34 AM, David Jacobson wrote:
>> On 2/13/14 4:49 PM, David McGrew wrote:
>>> Hi,
>>>
>>> the latest version of this draft is out.  Thanks are due to Jim 
>>> Schaad and Rob Napier for their feedback on version 02.
>>>
>>> The goals of this draft are to provide an authenticated encryption 
>>> scheme suitable for use in those cases where CBC and HMAC are 
>>> available, but no dedicated AE schemes are available.   Also, it 
>>> doesn't require deterministic nonces, which itself is useful in some 
>>> situations.
>>>
>>> It might be nice to add a description of how IVs can be 
>>> pseudorandomly generated.   It would be especially useful to 
>>> generate the IV using the same key as used for encryption, with an 
>>> unpredictable counter, or something like that.   Is anyone aware of 
>>> a security proof that could be cited for that sort of technique?   I 
>>> think that some systems would have a much easier time maintaining a 
>>> counter than they would generating truly random IVs, which is 
>>> reasonable motivation in my opinion.   Glad to hear other thoughts 
>>> on this subject.
>>>
>>> David
>>>
>>> --
>> [SNIP]
>>
>> Above you mention an unpredictable counter.  I suspect you mean a 
>> counter that begins at a secret value, and wraps in the obvious way.  
>> Therefore it has be generated at random and stored in secure 
>> non-volatile storage.  So it seems strictly harder than just 
>> randomness.  So I don't know what is gained by using an unpredictable 
>> counter.
>
> It would enable the algorithms to be used for encryption on devices 
> that lacked a random source, and it would allow other systems to avoid 
> the complication of calling a random source during each encryption 
> invocation.   I don't have a lot of trust in good random sources being 
> done correctly and being available. Maybe another good way to say it 
> is that the requirement to tap into good randomness or 
> pseudorandomness is a very significant external dependency.    For 
> example, if a non-crypto-specialist downloads the source code for 
> these ciphersuites off the Internet and links it to their application, 
> it would be much better to have no such external dependancy, since the 
> developer might not even understand the randomness requirement.
>
You may have missed my point.  If  by "unpredictable counter" you mean 
one where the starting value is secret and it is incremented modulo the 
counter range once for each message, then you need randomness to get the 
initial counter value.  So you haven't eliminated the need for 
randomness.  Now maybe you were thinking of something like the TICK 
counter available in some CPUs.  It is incremented once each clock tick, 
and hence is pretty hard for the attacker to predict exactly.

[SNIP]
> This draft consciously avoids key derivation for simplicity, and to 
> avoid potential complications around validation (especially FIPS-140 
> key derivation).
>
>
Thank you for clarifying that.  Thus the key you describe may be an 
abstraction for managed keys in a hardware security module, and you 
can't get to them, and it is hard to push new ones in.  That changes a 
lot of things.

There is another concern:  replay attacks.   There is no way for the 
receiver to differentiate between a genuine fresh message sent by the 
sender and a replay of that message sent by an attacker.  I suggest that 
you mention that fact in Section 6 (Security Concerns), and say that for 
applications where replay resistance is required, the application is 
responsible for implementing replay resistance. The data used to 
implement replay resistance (say a sequence number or time stamp) can 
safely be put in the unencrypted portion.

    --David Jacobson

[SNIP]