3 ms·

It used to be possible in openssh to use -c none and skip the overhead of encryption for the transport (while retaining the protection of rsa keys for authentic

It used to be possible in openssh to use -c none and skip the overhead of encryption for the transport (while retaining the protection of rsa keys for authentication). Even the deprecated blowfish-cbc was often faster than aes-ni for bulk transfers. I remember cutting off hours of wait time in backup jobs using these options. 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.

mmh0000 7mo ago
`-c none` hasn't worked in SSH for at least a decade. The `none` option was for SSHv1 which was already quite old when it was fully removed from OpenSSH 7.6 in 2017[1]. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html
- i_think_so 7mo ago
  Now that you mention it, I think that probably was around the the last time I used it. Time flies.
adrian_b 7mo ago
If blowfish was faster than AES, then it is certain that either the CPU did not support the AES instructions (AES NI = AES New Instructions), or the ssh program, either at the client or at the server was compiled without AES instructions support. 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.
- Veserv 7mo ago
  Do you have citations for sustained 0.5 core-cycles/byte (80 Gb/s)? The benchmarks I have seen are closer to ~20-30 Gb/core-s though I have heard claims of 40-50 Gb/core-s.
- i_think_so 7mo ago
  I don't remember which generation of Sparc CPU we were working with, but yes, Blowfish was faster. I made a matrix of relevant options and benchmarked all combinations.

mmh0000 7mo ago

`-c none` hasn't worked in SSH for at least a decade. The `none` option was for SSHv1 which was already quite old when it was fully removed from OpenSSH 7.6 in 2017[1]. https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html

i_think_so 7mo ago
Now that you mention it, I think that probably was around the the last time I used it. Time flies.

adrian_b 7mo ago

If blowfish was faster than AES, then it is certain that either the CPU did not support the AES instructions (AES NI = AES New Instructions), or the ssh program, either at the client or at the server was compiled without AES instructions support. 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.

Veserv 7mo ago
Do you have citations for sustained 0.5 core-cycles/byte (80 Gb/s)? The benchmarks I have seen are closer to ~20-30 Gb/core-s though I have heard claims of 40-50 Gb/core-s.
i_think_so 7mo ago
I don't remember which generation of Sparc CPU we were working with, but yes, Blowfish was faster. I made a matrix of relevant options and benchmarked all combinations.