Random (aka "unpredictable") IV protect against some attacks with certain modes. In general, it is enough for the IV to be unique.
Do you have a specific application in mind? I.e., how do you make sure the counter won't wrap around? (Yes I realize in your approach it's 2^32, and it counts blocks, not bytes.) Sent from my iPad > On Sep 29, 2015, at 17:26, Jean-Pierre Münch <jean-pierre.mue...@web.de> > wrote: > > > >> Am 29.09.2015 um 18:52 schrieb Martin Raiber: >> 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. > This sounds reasonable and really should be preferred compared to the method > of just using *one* IV / nonce more or less statically. BTW this is even > better than always choosing a random IV because a) you don't need to transfer > those and b) the chance of IV reuse is much lower as you won't expect > collisions from simply incrementing. > > BR > > JPM >> >>> 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 <nolo...@gmail.com> 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 cryptopp-user...@googlegroups.com. >>>> 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 cryptopp-user...@googlegroups.com. >>>> 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 cryptopp-users-unsubscr...@googlegroups.com. >> 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 cryptopp-users+unsubscr...@googlegroups.com. >> 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 cryptopp-users-unsubscr...@googlegroups.com. > 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 cryptopp-users+unsubscr...@googlegroups.com. > 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 cryptopp-users-unsubscr...@googlegroups.com. 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 cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
