3 ms·
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
by adrian_b 8mo 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 8mo agoDo 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 8mo agoI 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.