> Sorry to dig up an old thread.... > > There _can_ be another small risk when using GCM mode. I learned about it > when researching non-constant time increment functions. For information on > it, see "Should Increment functions be near-constant time?", > http://crypto.stackexchange.com/q/30261/10496. > > I looked at the library's GCM code, and we might want to place a > mitigation. > > I'm definitely voting for a mitigation. > We're a crypto library and thereby can't tolerate (potential) security > issues, especially if they are related to GCM - the most advertised mode. > > The how of the mitigation is a more difficult question though. >
Poncho's answer is good, and its the first one that came to mind to me. We've documented the potential risk in misc.h. Another potential mitigation is to use the second version of IncrementCounterByOne. That's the one with an input and output buffer. The trick is, when we call it, we use the same buffer for both input and output. That change ensures all elements in the array are touched. However, it means the code has to use memmove rather than memcpy because the buffers overlap. (Using memcpy with overlapping buffers is UB). 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.
