[haiku-commits] Re: BRANCH midar-github.package_signing [f5e4c70] src/libs/ed25519
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 27 Mar 2014 22:03:27 +0100
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.
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 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.
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.
Importing and having to maintain third-party code (particularly
code of that complexity and sensitivity) is something we should
really try to avoid.
It's a 1:1 import of the reference implementations with minor changes
by me.
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.
CU, Ingo
Other related posts:
