Failed to attach the log file. Now attached. Am 04.11.2015 um 18:56 schrieb Jean-Pierre Münch: > 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. >>> >>> 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. > > BR > > JPM > > ----- > OS: Win 7, x64, HP > RAM: 1333MHz DDR-3 RAM > CPU: i7-930 > Compiler: VS2015, Release x64, speed optimizing compiler flags (/O2 > /Ob2 /Oi /Ot) > Iterations: 2^33 > Tested Memory sizes: 2^{n}, n\in {1,2,4,8,...,11} bytes >> >> 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 >> <mailto: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 > <mailto: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.
Current buffer size: 1 bytes. Old method time: 18191332µs. Safe method time: 17013660µs. Overhead by new method: -6.47381% Current buffer size: 2 bytes. Old method time: 28337657µs. Safe method time: 57306797µs. Overhead by new method: 102.228% Current buffer size: 4 bytes. Old method time: 26907067µs. Safe method time: 40456989µs. Overhead by new method: 50.3582% Current buffer size: 8 bytes. Old method time: 26507308µs. Safe method time: 80870965µs. Overhead by new method: 205.089% Current buffer size: 16 bytes. Old method time: 26959259µs. Safe method time: 160368718µs. Overhead by new method: 494.856% Current buffer size: 32 bytes. Old method time: 26456508µs. Safe method time: 299867021µs. Overhead by new method: 1033.43% Current buffer size: 64 bytes. Old method time: 26426203µs. Safe method time: 576561456µs. Overhead by new method: 2081.78% Current buffer size: 128 bytes. Old method time: 26466084µs. Safe method time: 1183228852µs. Overhead by new method: 4370.74% Current buffer size: 256 bytes. Old method time: 26400793µs. Safe method time: 2296934772µs. Overhead by new method: 8600.25% Current buffer size: 512 bytes. Old method time: 26406970µs. Safe method time: 4516743827µs. Overhead by new method: 17004.4% Current buffer size: 1024 bytes. Old method time: 26431221µs. Safe method time: 8960170167µs. Overhead by new method: 33799.9% Current buffer size: 2048 bytes. Old method time: 26421294µs. Safe method time: 18193695953µs. Overhead by new method: 68760%
