libecc

[Stéphane Neveu]

Hi Lukas,

Here is the reply from the libecc devs :

Things are a bit more complex than this: you can not really store a
crypto library in the "vulnerable" or "non-vulnerable" box for
auxiliary channel attacks. Indeed, beyond the countermeasure
implementing operations at constant time at the algorithmic level
(which the libecc implements at best, see below), many elements
intervene (notably the compiler, as well as the target platform).

Moreover, it should be noted that even the most popular libraries
still suffer from attacks of this type:
- Either by the discovery of new sources of leaks side channel (see
https://www.tau.ac.il/~tromer/mobilesc/ on OpenSSL and CoreBitcoin).
- Either by new exploitation techniques not known so far (see
https://eprint.iacr.org/2013/448 on GnuPG).
- Either by negligence in the code with an algorithm not completely
constant time (see
https://security-tracker.debian.org/tracker/CVE-2016-7056 for OpenSSL,
the result of which was presented to Usenix 2017 this summer ).

To summarize a little and be transparent:
1) libecc implements constant time at the algorithmic level, but the
"painting is still fresh" in the sense that it still lacks some tests
to perform. Nevertheless the bricks are there.
2) libecc, because of the choice of portability, will never include
assembly. This choice has the consequence of leaving possibilities of
side channels after compilation via at least three main channels:
         - By the incorrect translation of the constant time between
the C and the assembly (by optimizing a test provided for the constant
time, by deleting it for example).
         - By using instructions that are not constant time, because
the targeted micro-architecture has a defect on these instructions.
         By using a unit of the CPU that is not known and not intended
to optimize the execution of the code, but inducing a leak that can be
exploited by an attacker.

Point 1) is part of the "work in progress" (but it can take time). The
point 2) will never be addressed in essence (or else via a warning in
the documentation recommending a review of the binary code generated
by a compiler X for a Y architecture).

All these elements imply that for the sake of transparency, we will
never put in the documentation libecc is "side channel attacks" proof
(and when a library boasts of it without further explanations and
nuances, it is better to be careful :-)).

Beyond all the debate on the side channels, it should be noted that
libecc can be without problem used:
- For * signature verification * (since in this case, side channel
attacks are not relevant).
- For offline signature generation by taking account of the local and
remote attacker model by side channel (for example by leaving the
machine disconnected, in the "wiping" after, ...).
- For non-critical operations * on NN, Fp and elliptic curves.

So despite the possible side channels, it remains in my sense an
interest in libecc (by putting ad hoc warnings well in the
documentation).


Regards,

Stéphane

2017-08-27 14:40 GMT+02:00 Stéphane Neveu <stefneveu at gmail.com>:
> Hi Lukas,
>
>>   Though some efforts have been made to have (most of) the core
>>   algorithms constant time, turning libecc into a library shielded
>>   against side channel attacks is still a work in progress.
>>
>> I think this means that the library is not yet ready for production use.
>>
>>
>> I'm stopping my review here, since at this point I don't think we
>> should package libecc in Debian (yet).  If you think otherwise,
>> convince me and I'll continue reviewing & working on the package
>> together with you :) .
>>
>
> You are absolutly right, I'll ask the guys maintaining the upstream
> code about it and I keep you in touch of course.
>
>> Regards
>> Lukas
>
> Thank you.
> Best regards,
>
> Stéphane