From: Joy Latten <latten@austin.ibm.com>
Subject: Re: GCM & CTR (fwd)
Date: Mon, 22 Oct 2007 16:01:18 -0500
Message-ID: <200710222101.l9ML1IG4026190@faith.austin.ibm.com>
Cc: linux-crypto@vger.kernel.org, mikko.herranen@cs.helsinki.fi
To: herbert@gondor.apana.org.au
Sender: linux-crypto-owner@vger.kernel.org

>On Fri, Oct 19, 2007 at 10:29:32PM +0000, Joy Latten wrote:
>>
>> I think the change to CTR would be simple.  
>> If noncesize + ivsize == blocksize, then use 
>> entire counterblock as counter and pass to  
>> ctr_inc_quad(). Currently, we just fail 
>> if noncesize + ivsize == blocksize.  
>
>How about adding an explicit counter size parameter?
>
>So intead of ctr(aes,4,8) for the standard IPsec CTR we'd have
>ctr(aes,4,8,4).  Then GCM can just use ctr(aes,4,12,4).

GCM begins encryption with the counter at 2. 
CTR initializes its counter with 1 to begin encryption.
GCM then uses counter set to 1, to create authentication
tag. It must do encryption first though because the
encrypted data is passed in to create authentication tag.
Encrypting with counter initialized at 2 doesn't quite
fit into CTR...

The only resolution I can readily think of is to
allow the user to pass in the counter. It could
be part of the IV.

Thus GCM could pass in IV || 0^31 || 1 to CTR for
encryption. It would then later pass in IV || 0^32 to
create authentication tag.

So, if noncesize + ivsize == blocksize, do not initialize
a CTR counter. Instead, use "countersize" bytes from end of
IV as counter to be incremented.

So ctr(aes,0,16,4) would indicate to use last 4 bytes
of IV for counter. 

Does this seem ok?

Would there be some concern of user initializing counter,
because it could be initialized to a high number... then 
counter could rapidly rollover? Would this be a problem? 
If so, then we could use entire counterblock for counter 
in this instance and not allow user to specify countersize...

Regards,
Joy