Re: [Openvpn-devel] [PATCH v2 1/3] Use crypto library functions for const time memcmp when possible

[Arne Schwabe <arne@...1227...>]

[-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --]

Am 26.04.20 um 11:34 schrieb Gert Doering:
> Hi,
> 
> On Sun, Apr 26, 2020 at 11:25:49AM +0200, Steffan Karger wrote:
>>>> well, sometimes to adhere to the codestyle, you have to re-arrange code :)
>>>
>>> "rearrange" and "rewrite in a not easy to understand way" (which looks
>>> a bit overthought to me, TBH - unlike "secure memzero" I cannot see an
>>> obvious reason why all that volatile would be relevant).
>>
>> This secure memcmp is relevant to avoid timing side channels in e.g.
>> authentication tag compare. Think about the HMAC in our tls-auth/crypt
>> and the HMAC of (non-AEAD) data channel packets.
> 
> I do understand why it has to be constant *time*, in regards to "do the
> compared buffers differ or not".
> 
> I do not see how all this "volatile" and "copy from pointer to variables
> to other stuff" handwaving is going to make any difference wrt constant
> time comparison.
> 
> And it hurts my eyes.

Yeah the goal is basically do what the crypto library is doing. And if
you play with godbolt. So we don't need to go down this path of having
to come up with our own version.

And if you care about speed then we should definitively go for OpenSSL's
memcmp function. Since it is implemented in assembler it does not try to
breaks the compiler compilation optimisation with volatile that might
trigger more memory loads than necessary but can be a small fast
constant time function.

If you play a bit with godbolt.org (https://godbolt.org/z/gXgcC9) you
will see that the code that is generated from our current version is not
yet optimised to non constant versions but especially the clang compiler
is getting close. It completely optimises away the function for compile
strings (main2 just becomes return 95), builds a version optimised for
one fixed string and vectorises the generic version. So I am not sure if
these variants still have their constant with modern processes and
speculative execution.

Arne



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]