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

[David McGrew <[e-mail]>]

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
>>
>> --
> There is a mismatched parenthesis in the first sentence of Section 2.4.
>

got it.

> It seems that your intent is to truncate the MAC to the length of the 
> MAC_KEY.  Also these two seem to be half the size of the hash function 
> output block size.  However, that is not explicitly stated.  I suggest 
> you mention that somewhere.

Added this to the rationale.

<t>
The algorithms in this note truncate the HMAC output to half of the
size of the output of the underlying hash function.  This size is the
recommended minimum (see Section 5 of <xref target="RFC2104"/>), and
this parameter choice has withstood the test of time.
</t>

>
> Above you mention generating the IV with the same key as is used for 
> encryption.  Note that this is in conflict with Section 3, which says 
> "However, if a pseudorandom method is used, that method MUST NOT make 
> use of ENC_KEY or MAC_KEY."  Maybe you are thinking the we CFRG people 
> can come up with a safe way to use the encryption key, but you don't 
> trust users to do that.

RIght; if there is a security analysis somewhere that I can cite, I 
would like to do so.   Otherwise, I want to leave it out.

>
> 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 have chosen to avoid nonces, but instead to require randomness.   
> It is debatable whether this is a good tradeoff.  I suspect it would 
> be better to have a system that requires a nonce, where the only 
> requirement is that it is doesn't repeat (or is sufficiently unlikely 
> to repeat, to allow for random nonces if the user finds that convenient). 

Respectfully disagree.   The goal here is not to develop a new AEAD 
algorithm, but rather to show people how they can construct a good AEAD 
out of the CBC and HMAC components that they probably have in their 
toolkits.   The Rationale sections outlines the goals.

> Examples of suitable nonces are a counter, time, or random.  You could 
> compute the IV  as SHA256(E_ek(nonce)) and use only the first 128 
> bits.  E_ek means encrypt with the encryption key.  This doesn't leak 
> an ECB mode plaintext-ciphertext pair to an attacker, even if he knows 
> or can easily guess the nonce (e.g. when the nonce is time or when he 
> knows the number of messages that have been sent).  Since the attacker 
> doesn't know the encryption key, he can't predict the nonce.
>
> You have a key that is the concatenation of the MAC_KEY and the 
> ENC_KEY.  This might tempt lazy or incompetent implementers  do 
> something stupid.  You might consider deriving the MAC_KEY and ENC_KEY 
> from a single key.  If you did that, you could generate the MAC_KEY, 
> ENC_KEY, and IV like this.  Use HMAC(key, 0x1 || counter) to generate 
> enough bits for MAC_KEY and ENC_KEY.  Use HMAC(key, 0x2 || nonce) to 
> compute the IV.  (This is a different proposal for the IV than the 
> last paragraph.)  Even if the attacker can predict the nonce, he 
> cannot predict the IV because he doesn't know the key.

This draft consciously avoids key derivation for simplicity, and to 
avoid potential complications around validation (especially FIPS-140 key 
derivation).

>
> If you really don't want to accept a nonce, have the library generate 
> its own nonce with something from inside the system, such processID || 
> date_time || message_counter_in_this_process. (Remember, this only has 
> to be unique within users of the same key.  It doesn't have to be 
> world-wide unique.)  The downside is that any such scheme is specific 
> to a particular system.  I think most of us would rather say "compute 
> this and pass it in as the nonce" than "modify the code to collect this".
>
> As to the question you actually asked, I don't see that you can have 
> randomness in the encryption if you don't have either randomness as an 
> input or use a nonce.  It is completely deterministic and the same 
> message will be encrypted the same every time.  However, you can do a 
> bit better.  In some applications the authenticated but unencrypted 
> part (called A in the draft) will contain a sequence number or 
> timestamp.  If you compute MAC_KEY, ENC_KEY, and IV similar to the way 
> in the last paragraph, but change the IV computation to HMAC(key, 0x2 
> || A). Absolutely identical messages will result in the same bits over 
> the channel, but if the unencrypted part contains a sequence number or 
> timestamp, the encrypted part will be randomized.  My final suggestion 
> is to compute IV as HMAC(key, 0x2 || length(A) || A || nonce).  This 
> way, users who supply non-repeating nonces get randomized encryption, 
> and even if they mess up, they will get randomized encryption if the A 
> part has a time stamp or sequence number.

Thanks for your comments and feedback.   You bring up some valid 
considerations, some of which fall outside the particular (modest) goals 
of this draft.

David

>
>     --David Jacobson
>
>>
>> A new version of I-D, draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt
>> has been successfully submitted by David McGrew and posted to the
>> IETF repository.
>>
>> Name:		draft-mcgrew-aead-aes-cbc-hmac-sha2
>> Revision:	03
>> Title:		Authenticated Encryption with AES-CBC and HMAC-SHA
>> Document date:	2014-02-13
>> Group:		Individual Submission
>> Pages:		29
>> URL:http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt
>> Status:https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/
>> Htmlized:http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-03
>> Diff:http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-03
>>
>> Abstract:
>>     This document specifies algorithms for authenticated encryption with
>>     associated data (AEAD) that are based on the composition of the
>>     Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)
>>     mode of operation for encryption, and the HMAC-SHA message
>>     authentication code (MAC).
>>
>>     These are randomized encryption algorithms, and thus are suitable for
>>     use with applications that cannot provide distinct nonces to each
>>     invocation of the AEAD encrypt operation.
>>
>>
>>
>> 	
>>
>> 	
>>
>> 	
>>
>> 	
>>
>>                                                                                    
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> .
>>
>>
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg