I see this project's main value in turning loose the power of multiple cores on a filesystem full of manifold directories, backed by flash based storage that only runs optimally at queue depth >1 (which is most of them). On spinning rust this will probably just thrash the heads.
Hmmm. I wonder how 2 or 3 threads perform with zfs and a reasonable sized ARC?
This discussion should drive home the importance of not listening to conventional wisdom and presuming optimal performance without actually testing your options. And particularly, don't presume that a blog post (or an LLM that scraped it) knows what's right for your particular use case.
Sadly it appears those days are gone now. 3des is still supported, probably for some governmental environments, but it was always a slower algorithm. Unless there are undocumented hacks I think we're stuck with using proper crypto. Oh darn.
The `none` option was for SSHv1 which was already quite old when it was fully removed from OpenSSH 7.6 in 2017[1].
Blowfish is many times slower than AES on any CPU with AES instructions. Old CPUs with AES support needed around 1 clock cycle per byte, but many modern CPUs need only around 0.5 clock cycles per byte and some CPUs are even twice faster than this.
0.5 clock cycles per byte means a 10 GB/s = 80 Gb/s encryption throughput per core @ 5 GHz, so only for 100 Gb/s or faster Ethernet you might need to distribute encryption on multiple cores to reach full network link throughput.
For full AES speed, one must not use obsolete modes of operation like CBC or obsolete authentication methods like HMAC. For maximum speed, one must use either aes128-gcm@openssh.com or aes128-ctr + umac-64@openssh.com.
For increased security at lower speed, one can use aes256-gcm@openssh.com or aes192-ctr or aes256-ctr with umac-128@openssh.com.
In general, one should never use the default configuration of ssh for cipher and MAC algorithms, but one should delete all obsolete algorithms and allow only the few without problems, unless one has to make connections to legacy systems.