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