Neither nonce nor IV need to be secret. You want to ensure/guarantee that the combination of key + IV/nonce + counter never repeats. That includes taking care of counter wrap-around.
Sent from my iPad > On Sep 29, 2015, at 12:52, Martin Raiber <[email protected]> wrote: > > 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]> 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. -- -- 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.
