Thanks! I did some further research and the general idea seems to be good. 
They are even moving from the explicit nonce in TLS v1.1 and v1.2 to 
(again) a fully implicit nonce in TLS v1.3 
(https://tools.ietf.org/html/draft-ietf-tls-tls13-07 ). 

The implementation I had in the original message, however, is broken. For 
AES-GCM it only uses the last 4 bytes for counting, so there is indeed the 
danger of wrap-around. Additionally it seeks back to the original nonce on 
the end of the message to generate the MAC (see 
https://en.wikipedia.org/wiki/Galois/Counter_Mode#/media/File:GCM-Galois_Counter_Mode.svg
 
), so the nonces would be reused.

I'm going to do the following:

   - Generate a fully random 96-bit nonce for the first message and 
   transmit that unencrypted
   - Increment this nonce after every message via IncrementCounterByOne and 
   use that for the next message
   
That would be nearly identical to the TLS v1.3 scheme, except the nonce is 
not partially secret.

On Tuesday, September 29, 2015 at 3:47:26 AM UTC+2, Mouse wrote:
>
> I do not like this. An IV is supposed to be unique per multi-block 
> message, within which the increasing counter takes care of individual 
> 128-bit blocks. You're trying to treat the data stream as one huge 
> "super-message" with one IV. It is a corner that I personally choose not to 
> cut. There are too many subtle things (e.g. Counter length, wrap-around, 
> etc) that I prefer not to deal with.
>
> Having access to the source, you can make that modification for yourself.
>
> I will object against including it in the main Crypto++ code base.
>
> @Jeffrey, security context is key + IV + counter (which usually is 
> implemented as a mutable part of IV). As I understand, the OP wants to keep 
> the IV the same across multiple messages, relying on the expectation that 
> the counter (a) will not reset from one message to the next, and (b) will 
> not wrap around in the process.
>
> Sent from my iPad
>
> On Sep 28, 2015, at 17:57, Jeffrey Walton <[email protected] <javascript:>> 
> wrote:
>
>
>
> I'm using AES-GCM to send multiple messages (CryptoPP::GCM<CryptoPP::AES>) 
>> via AuthenticatedEncryptionFilter.
>> It seems I need to resynchronize the underlying GCM cipher after each 
>> message with a call to Resynchronize which
>> needs a new iv as argument.
>>
>> I see no reason why this new iv is neccessary. GCM uses a counter, so the 
>> "iv" is a nonce, not necessitating
>> a fully random iv. Internally GCM increments the nonce for every AES 
>> block, so at the point one has to resynchronize it,
>> it is already at a usefull last_iv+1.
>>
>> Does anything break by extending CryptoPP::GCM by a resynchronize method 
>> which does not change the iv, like:
>>
>> class CtrNonceGCMEncryption : public CryptoPP::GCM<CryptoPP::AES >::
>> Encryption {
>> public:
>>     void Resynchronize() { m_state = State_IVSet; }
>> };
>>
>> and using this method instead (as well as in Decryption)? This would save 
>> on random nonce generation and transmission.
>>
>
> The reasoning makes sense to me. I don't believe you're violating security 
> requirements because the security context is unique per message.
>
> The one thing I would verify is GCM's IncrementCounter() function gets 
> called when MessageEnd() is propagated to ensure you're not reusing your 
> accidentally reusing the last IV. That's the sort of optimization (defer on 
> the increment unless its needed) Wei would provide.
>
> Also see GCM's source at 
> http://www.cryptopp.com/docs/ref/gcm_8cpp_source.html.
>
> Jeff
>
> -- 
> -- 
> You received this message because you are subscribed to the "Crypto++ 
> Users" Google Group.
> To unsubscribe, send an email to [email protected] 
> <javascript:>.
> More information about Crypto++ and this group is available at 
> http://www.cryptopp.com.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Crypto++ Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at 
http://www.cryptopp.com.
--- 
You received this message because you are subscribed to the Google Groups 
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to