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

[David Jacobson <[e-mail]>]

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.

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.

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.

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.

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

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.

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