Mailing List Archive

[patch 1/2] use chacha20 from openssl (1.1.0+) when possible
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@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.
Re: [patch 1/2] use chacha20 from openssl (1.1.0+) when possible [ In reply to ]
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@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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev