[PATCH v2 1-2/2] use ecdh/X25519 from openssl when possible (openssl-1.1.1+)

[Yuriy M. Kaminskiy]

On 20.02.2019 07:34, Ben Lindstrom wrote:
> Suspect you'd get more traction by targeting libressl.  As that is what upstream uses.

Assuming libressl README.md is up to day ...
=== cut ===
  The current common API subset is OpenSSL 1.0.1.
=== cut ===
... this is impossible (they rely on 1.1.0 and 1.1.1 api). And given lack of
assembler optimization in libressl for anything interesting (chacha, poly1305,
x25519), it will be rather pointless or worse.

It looks like only "libressl-targeted" thing in this patches that should
be done, is to ensure they are not accidentally enabled in combination
with libressl.

> Yuriy M. Kaminskiy wrote on 2/18/19 2:29 PM:
>> On 17.02.2019 15:46, Yuriy M. Kaminskiy wrote:
>>> See attached:
>>>
>>> (1) patch against 7.9p1, tested with openssl 1.1.0j and openssl
>>> 1.1.1a on linux/i386; passes regression test and connects to
>>> unpatched sshd without problems;
>> As ed25519-from-openssl patch came out a bit less convoluted, I've
>> tried to do same with ecdh/x25519.
>>
>> So, here are V2:
>> (1) use openssl-1.1.1a api,
>> (2) [optional] emulate openssl-1.1.1a api for openssl-1.1.0.
>>
>> Unfortunately, it was a bit slower (as it needs to (de)serialize
>> private key):
>>
>>> I hacked a bit regress/unittests/kex, and benchmarked
>>>     do_kex_with_key("curve25519-sha256 at libssh.org", KEY_ED25519, 256);
>>> Before:
>>>   0.3295s per call
>>> After:>   0.2183s per call
>> openssl/1.1.0j, curve25519 + ecdsa-sha256 (openssh's builtin eddsa is too slow,
>> so difference between V1 and V2 is lost in noise, so I replaced ed25519
>> with ecdsa/p256 for this test)
>>
>> ecdh/25519 V1:
>>    0.0185s per call
>> ecdh/25519 V2:
>>    0.0205s per call
>>
>> openssl/1.1.1a, curve25519 + ed25519 (with ed25519 patch)
>> ecdh/25519 V1:
>>     0.0115s per call
>> ecdh/25519 V2:
>>     0.0131s per call (worse by 14%)
>>
>>> That is, 50% speedup; assuming ed25519 (added to openssl in 1.1.1)
>>> takes about same time as ecdh/x25519, there are potential for total
>>> 200% speedup in KEX.
>>>
>>> (2) rebased patch against git master; passes regression test;
>>>
>>> I relied on presence of NID_X25519 for autodetection; probably it
>>> makes sense to check if is actually working it autoconf; then again,
>>> maybe not (it won't work when cross-compiling anyway).
>>>
>>> P.S. given amount of feedback I received so far, it seems everyone
>>> follows motto "it cannot be secure if it is not slow".