[haiku-commits] Re: BRANCH midar-github.package_signing [f5e4c70] src/libs/ed25519
- From: Jonathan Schleifer <js-haiku-commits@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 24 Mar 2014 19:03:15 +0100
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:
>> f5e4c70: Import ed25519 from openssh-6.6p1
>
> I wonder, isn't that provide by openssl already?
Nope, OpenSSH does not offer Ed25519 yet.
> 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. 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. It also depends heavily on
the nonce: Reuse it once and your secret key can be recovered. Also, the NIST
curves don't provide the best properties to use it for ECC. See
http://safecurves.cr.yp.to. I'm not confident enough to implement ECDSA or RSA
without creating any of these problems.
Ed25519 does not have all these problems, is licensed as public domain and is
quite fast. It is designed as a ready-to-use solution which does not give you
much opportunity to do things wrong. See http://ed25519.cr.yp.to
> 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.
What I changed is to use SHA-512 from OpenSSL instead of the integrated one, as
that is streamable. That allows to not having to copy the message just to
create sha512(r,a,m) and sha512(extsk[32..63],m).
The next change I'm thinking about will be incompatible, though:
sha512(r,a,m) and sha512(extsk[32..63],m) are both generated when signing, but
have the unfortunate property that they require hashing the message twice, and
r is generated with the result of sha512(extsk[32..63],m). Therefore I want to
change it to sha512(m,r,a) and sha512(m,extsk[32..63]). This should not matter,
as the strength of the SHA512 should be unchanged by that, but this allows
creating an SHA512 context, hashing the message, NOT finalizing the hash,
copying it and then just adding extsk[32..63] / r,a to the unfinalized hash.
Thus we avoid double-hashing and are streaming-capable, thus we don't need to
have the full uncompressed heap in memory.
Before doing that change, I'd like to discuss it with others, though
(cryptographers, that is). Does anybody know a mailing list where I could ask
about this?
--
Jonathan
Other related posts:
