On Wednesday, November 4, 2015 at 12:56:12 PM UTC-5, jean-pierre.muench wrote: > > Am 04.11.2015 um 03:08 schrieb Jeffrey Walton: > > > 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> >> 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). > > Interesting idea, although I fear that a timing side channel may remain > (two dozen carries may take longer than no carry) and thereby not fixing > the problem (if I'm reading things right). > > But anyways I got the analysis data. The reproduction details are > documented below and I appended the log file that was created. > > The highlights: > We get a 50% speed penalty best-case for the 4 byte counters. > We get a small speed increase for 1 byte counters (unexpected). > The overhead seems to scale linearly with the byte count. > > My idea: > It was stated that a timing leak may only be an issue in a few selected > situations. > I thereby propose adding an additional parameter bool (template / > run-time) to the IncrementCounterByOne function allowing to switch to the > constant-time or the faster version. We could default to "usesafe" and only > switch in confirmed-harmless scenarios. >
Yes, I'd like to see that, too. For those who want the mitigations, they can have it. For those who don't care, they can avoid them. We'll have to put that on the TODO list if its not already there.... The library also has the opposite: it has code with timing mitigations that cannot be disabled. For example, Rijndael uses AliasedWithTable to avoid timing attacks on AES (see around line 980 of http://www.cryptopp.com/docs/ref/rijndael_8cpp_source.html#l00980). 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.
