[haiku-commits] Re: BRANCH midar-github.package_signing [f5e4c70] src/libs/ed25519

  • From: Jonathan Schleifer <js-haiku-commits@xxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 27 Mar 2014 22:25:39 +0100

Am 27.03.2014 um 22:03 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:

> On 24.03.2014 19:03, Jonathan Schleifer wrote:
>> Am 24.03.2014 um 17:24 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
>>> On 03/23/2014 01:01 AM, midar-github.package_signing wrote:
>>> If not, why not use ECDSA [1] instead?
>> 
>> It has various flaws. For starters, it uses the NIST curves that are
>> believed to be backdoored.
> 
> AFAIK, openssl provides not only NIST curves for use with ECDSA.

Then you could maybe implement Curve25519 using it. Still, Ed25519 has more 
advantages, like not having a nonce that allows leaking the secret key.

>> It also has several other flaws: Basically
>> in order to implement it efficiently, you need to use branches and
>> random array accesses and thus create a side channel to leak secret
>> keys.
> 
> How is that even relevant to our use case?

It is as soon as we sign packages in a process that a user can trigger.

>> It also depends heavily on the nonce: Reuse it once and your
>> secret key can be recovered.
> 
> That sounds like a problem of a broken implementation.

You mean reusing a nonce is a problem in the implementation? That can happen 
quickly. It can happen to big corporations like Sony, even when their business 
model depends on it. I'd say it's a flaw in the design, not the implementation. 
And Ed25519 doesn't have that problem.

>> Also, the NIST curves don't provide the
>> best properties to use it for ECC. See http://safecurves.cr.yp.to.
> 
> This seems to primarily focus on ECC used for communication. I don't see how 
> it is relevant for our use case if a curve has suboptimal properties for 
> interactive communication. It is not even important that it is fast, since 
> the time for hashing the package far outweighs the signature computation time 
> anyway.

Only the timing attacks' relevance is limited to communication. The rest is 
always relevant.

> The thing about imported third party code is that it tends not to be 
> maintained very well. An issue in that implementation discovered in two years 
> from now might not be noted by us and ported. Following the release cycle of 
> an actively maintained third party project is a lot more reliable in practice.

Well, we could either track SUPERCOP or NaCl. We'll notice if they change 
something and can port the change to our modified variant. We'll also notice if 
OpenSSH suddenly tells people to urgently upgrade their OpenSSH if they are 
using Ed25519.

--
Jonathan

Other related posts: