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.
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
> [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.
