(Here's a copy of a message I posted yesterday on the 'wrong' crypto
list. Sorry for any inconvenience this may have caused to those who
were cc'd.)
Hello,
We've been wondering about a slight compatibility glitch between
CTR and GCM with Joy Latten. As CTR and GCM are very similar, the
way to go with GCM is obviously to implement it on top of CTR.
The problem is that CTR and GCM use different counter portion
values for the first encrypted plaintext block. (They both start
at 1 but GCM uses the first value for authentication.)
How to communicate the different value to CTR? The best way seems to be
to spawn CTR as ctr(alg,0,16) in GCM and pass the contents
of the entire counter block in the IV. But then the size of the
counter portion will be set to 0 in CTR. We could modify CTR to
set the size of the counter portion to blocksize whenever
ivsize == blocksize. Or we could introduce an additional template
parameter for specifying the counter portion size. The former is
the easiest way to go if embedding a bit of GCM-specific code
inside CTR module is not a problem. Any opinions on this?
--
Mikko Herranen
On Fri, 2007-10-19 at 23:03 +0300, Mikko Herranen wrote:
> (Here's a copy of a message I posted yesterday on the 'wrong' crypto
> list. Sorry for any inconvenience this may have caused to those who
> were cc'd.)
>
>
> Hello,
>
> We've been wondering about a slight compatibility glitch between
> CTR and GCM with Joy Latten. As CTR and GCM are very similar, the
> way to go with GCM is obviously to implement it on top of CTR.
> The problem is that CTR and GCM use different counter portion
> values for the first encrypted plaintext block. (They both start
> at 1 but GCM uses the first value for authentication.)
>
> How to communicate the different value to CTR? The best way seems to be
> to spawn CTR as ctr(alg,0,16) in GCM and pass the contents
> of the entire counter block in the IV. But then the size of the
> counter portion will be set to 0 in CTR. We could modify CTR to
> set the size of the counter portion to blocksize whenever
> ivsize == blocksize. Or we could introduce an additional template
> parameter for specifying the counter portion size. The former is
> the easiest way to go if embedding a bit of GCM-specific code
> inside CTR module is not a problem. Any opinions on this?
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.
Let me know if this sounds ok, and I will
code it.
Regards,
Joy
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).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>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
On Mon, Oct 22, 2007 at 04:01:18PM -0500, Joy Latten wrote:
>
> So ctr(aes,0,16,4) would indicate to use last 4 bytes
> of IV for counter.
>
> Does this seem ok?
Yeah that looks fine. Although GCM also has a salt/IV split
so it'd use ctr(aes,4,12,4).
> 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...
Rolling over is not the issue. What would be a problem is if
it rolls over to the same value. However, that would require
(for a 4-byte counter block) 2^32 blocks of data.
I think it's sufficient to let the caller worry about issues
like this.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt