[patch 1/2] use chacha20 from openssl (1.1.0+) when possible

[Damien Miller]

On Thu, 17 Jan 2019, Yuriy M. Kaminskiy wrote:

> On some cpu's optimized chacha implementation in openssl (1.1.0+) is
> notably faster (and on others it is just faster) than generic C
> implementation in openssh.
> 
> Sadly, openssl's chacha20-poly1305 (EVP_chacha20_poly1305) uses
> different scheme (with padding/etc - see rfc8439) and it looks it is not
> possible to use in openssh.
> 
> OpenSSL 1.1.1+ also exports "raw" poly1305 primitive, but I
> have not tried it yet (it was not in 1.1.0).
> 
> Trivial benchmark:
> time ssh -c chacha20-poly1305 at openssh.com -S none -o Compression=no \
> localhost 'dd if=/dev/zero bs=100000 count=10000' >/dev/null
> (comparing "user time" only)
> 
> openssh: 7.9p1, self-compiled, based on upstream package from debian/unstable,
> hostkey - ecdsa/p256, pubkey auth key - ecdh/p256
> 
> Machine: pretty old amd k8 (w/ SSE2, but no SSSE3/AVX/AESNI)
> OS: linux/debian/stretch, openssl 1.1.0j-1deb9u1
> i386: speed: +8%
> amd64: speed: +10%
> 
> Machine: raspberry pi 3b+ (BCM2837B0, 4-core Cortex-A53 @1.4GHz)
> OS: raspbian/stretch
> 
> baseline: armhf/raspbian: unpatched ssh-7.9p1: 30.8s
> 
> with openssl 1.1.0j-1deb9u1 from raspbian (compiled for armv6 without neon):
> 
> armhf/raspbian: 24.7 seconds, speed: +25%
> 
> with openssl 1.1.0j-1deb9u1 from debian/stretch/armhf (compiled for
> armv7 with neon autodetection):
> armhf: 22.2 seconds, speed: +39%
> 
> Patches against 7.9p1 (tested) and git master (untested, only resolved
> configure.ac conflict) attached.

Thanks for this - it seems to work okay with OpenSSL when patched to
-current, but when I adapt it for OpenBSD/LibreSSL the encryption is
broken and the connection fails right after KEX.

I expect that there is some difference between OpenSSL and LibreSSL wrt
IV lengths or something. OpenSSH does need to support both, so this will
take a little figuring out.

One comment on the patch itself: it passes do_encrypt though in a bunch
of places and I'm not sure the usage is correct in all of them. In fact
I don't think it can even be made consistent for decryption, as the
ctx->main_evp has to be used in encryption mode (not decryption) to
generate the poly1305 key.

Given this is a stream cipher and there is AFAIK no difference between
encryption and decryption, I think it would be better just fix do_encrypt
to 1 to avoid inconsistency.

-d