On Monday, September 28, 2015 at 9:47:26 PM UTC-4, 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. >
If I parsed it as intended, I believe Martin wanted to use the next sequential IV, as if the GCM<AES> object retained its state. This, of course, means he ensures IncrementCounter() is called after MessageEnd(), even for a message smaller than the block size. I can't really find anything wrong with it because it meets security requirements of a unique security context per message. Perhaps I'm missing something. Putting personal objections aside, how does that *not* meet the security requirements of the mode? Jeff -- -- 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.
