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 <[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: >> >> | >> classCtrNonceGCMEncryption:publicCryptoPP::GCM<CryptoPP::AES >> >::Encryption{ >> public: >> voidResynchronize(){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 >> <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 >> <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] > <mailto:[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.
