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@xxxxxxxxxxx -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@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev