1

From a security standpoint, there are few good cipher options to use with SSH, such as ChaCha20, AES 128/256 GCM/CTR. As I understand (please correct me if I wrong), all of these offer pretty strong encryption.

However, what are the performance differences between aforementioned ciphers? In certain SSH tunneling applications (like tunneling NFS, for example) the performance is absolutely critical. How does one chose the cipher for the best performance, while maintaining reasonable security?

Of course I could just try and measure the difference, but this data will only be applicable to my specific hardware and particular measurement technique (in my simple benchmark AES 128 GCM seems to show the best results both in terms of throughput and low CPU load).

Speaking more general (and assuming CPU has AES-NI support):

  1. Does ChaCha20 take advantage of AES-NI?
  2. Is GCM mode faster than CTR?
  3. How does key size (128 vs 256) affects performance?
  4. Apart from the raw throughput, what ciphers tend to load CPU more?
  • SSH tunnel? I think the cipher does not matter. The bandwidth of the common processor and RAM is a couple orders of magnitude larger than the network bandwidth... – ThoriumBR Jan 6 at 19:28
  • @ThoriumBR, I think it depends on use-case. If SSH server is running on low-power energy efficient CPU (Celeron in my case) with 1G network, then CPU load becomes significant. Of course, part of it is probably caused by copying data across kernel/user space boundary, but ciphers also have measurable impact. – Oleg Jan 6 at 20:49
  • Well, RC4 is likely the fastest, but is also the least secure. – forest Jan 6 at 23:17
  • @Oleg Yes, I know, that why the common processor.... – ThoriumBR Jan 7 at 0:12
2

The realms of cryptography are plagued with challenges including how to get the best security with the least amount of wait time for the user.

Fundamentally, encryption speed comes down town a couple of factors.

  1. How many rounds of encryption are required.
  2. How much data is required per round.
  3. Block Cipher vs. Stream Cipher.

When discussing symmetric key algorithms, there are two categorical types, block and stream. In fact, you mentioned two in your question: ChaCha20 which is a stream cipher and AES which is a block cipher. The difference comes down to the way the encryption is applied to data (bit by bit or block by block). In the case of ChaCha, it streams data in specific block sizes. Due to the fundamental differences in operation (and light research) ChaCha20 is not based upon AES and wont likely have improved performance from Intel's NI technology.

For more information on ChaCha20 vs AES see here:

https://crypto.stackexchange.com/questions/34455/whats-the-appeal-of-using-chacha20-instead-of-aes

Also related to GCM vs CTR:

https://crypto.stackexchange.com/questions/14747/gcm-vs-ctrhmac-tradeoffs

Moving onto keysize, the bigger the key the more computational strength required to properly perform encryption or decryption. The more data required to perform the encryption will increase your decryption/encryption times. However, by doubling key length, you are exponentially increasing the level of difficulty to crack a key, not merely doubling it. This is why certain researchers may discourage smaller key sizes (such as AES128) and encourage adoption of larger keys (AES 256). It's the same fundamental protocol, but breaking the encryption is much more costly for the attacker.

Going on to the fourth sub question, I would recommend reading the post above on the appeal of ChaCha20 vs AES. Though it is a singular example, it discusses how the mathematics of encryption do not always align with computational process. This is why ChaCha20 can be performed quicker than AES even though it may iterate 20 rounds of encryption instead of ten or more with AES. Summarized, identically sized keys will operate differently based on the ability of the processor to churn through the data based on the mathematical computation required.

Lastly, you asked about the security of the tunnel over all. In reality, a high security payload is better off being encrypted and decrypted before being packaged for transmission to begin with. This will further challenge an attacker because your data security is not compromised if your network channel is; even if a man in the middle attack is successful.

As a security architect, my job is to determine what the "right" level of security is for a business process. This turns out a high number of variables including what the potential risk factor is, cost to the company in the event of breach, perceived valued of the data, cost to mitigate, and more. If you're trying to protect a public share, then a lighter security scheme is required than if you're protecting a security data lake. Being able to account for the business and technical requirements will help dictate your needs.

In your example of a file share, if speed of access and least impact to network are of highest importance, then a smaller encryption key size and lightweight cipher will benefit your business use case. If you're trying to prevent loss of sensitive data, then increasing key size and even choosing a slower algorithm may be justified. The point is that the "right" encryption may be different depending on your use case, even within the same company.

  • AES uses 10 to 14 rounds, not one... – forest Jan 6 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.