RE: [dev-crypto-csharp] question about AES-GCM counter implementation

[Sid Shetye]

Thanks Peter, it's been sometime since I read that paper - appreciate the
insight.

I'm also trying to understand some code that probably relates to a use case
that's not obvious to me

In
        GcmBlockCipher.DoFinal() 
we have, at the end,
        Reset(clearMac:false);
Which in turn triggers:
            ...    
            if (clearMac)
            {
                _macBlock = null;
            }

            if (_initialAssociatedText != null)
            {
                ProcessAadBytes(_initialAssociatedText, 0,
_initialAssociatedText.Length);
            }
            ...

Question:
1. Why do we care about preserving the _macBlock reference if we're done
with even the final block?
2. Why is there the ProcessAadBytes() again in the Reset() section? I was
under the impression we were done with the AAD at the beginning,  inside
Init() itself.

I suspect the above two are related to a specific use case. Would appreciate
your comments.

Thanks
Sid

-----Original Message-----
From: Peter Dettman [mailto:p...@lockboxlabs.com] 
Sent: Sunday, March 10, 2013 9:06 PM
To: 'dev-crypto-csharp@bouncycastle.org'
Subject: Re: [dev-crypto-csharp] question about AES-GCM counter
implementation

Hi Sid,
Incrementing of the counter is described in the spec
(http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-
spec.pdf)
as follows:
"Successive counter values are generated using the function incr(), which
treats the rightmost 32 bits of its argument as a nonnegative integer with
the least significant bit on the right, and increments this value modulo
2**32. More formally, the value of incr(F || I) is F || (I 
+ 1 mod 2**32)."

Whilst counter values should not be reused (GCM limits the message length to
just under 2**32 blocks - see Table 2), they may still "wrap around", so the
loop must be explicitly limited to the last 4 bytes. 
Where the nonce is exactly 96 bits, the counter starts at 1, so it won't
overflow, but for nonces of other lengths the counter is initialised to the
output of the hash function and so the guard is necessary.

Regards,
Pete Dettman