Hi,
The main advantage of your contribution is a speed increase. The
disadvantage is that your implementation has not been reviewed for
security by experts yet, and thus is not as reliable as the reference
implementation.
I believe OpenSSH (and libssh from my pov) is not the right place to
introduce experimental cryptographic code. The speed increase advantage
is not very relevant to SSH, because the key exchange happens only once
per session (on average), and we were using much slower algorithms till
last year (DH and ECDH), that nobody ever complained about.
You should probably try to get that code to be part of OpenSSL. I
Believe cryptographic implementations should go in crypto libs, and we
should bundle/maintain as little crypto code as possible in crypto
consuming projects.
Aris
Le 10/06/15 05:16, Mehdi Sotoodeh a écrit :
I have developed a compact at the same time high performance library for
curve25519/ed25519 and I have placed it in the public domain. It support DH
key exchange as well as ed25519 keygen, sign and verify. The implementation
is constant-time, supports blinding, bulk-verify and more.
The library is available as portable-C as well as ASM for Intel-x64 CPUs.
It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
target.
You may have a look at the source code hosted at:
https://github.com/msotoodeh/curve25519.
I was wondering if OpenSSH is a suitable home for this library?
Thanks, Mehdi.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
