this post was submitted on 01 Sep 2024
33 points (97.1% liked)

Linux

5237 readers
93 users here now

A community for everything relating to the linux operating system

Also check out !linux_memes@programming.dev

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] Toes@ani.social 3 points 2 months ago (1 children)

I noticed a pretty extreme difference in performance in openssh when using x11 forwarding when I touch the cipher suite.

AES128-ctr vs AES128-gcm on kubuntu 22.04.

I was wondering if anyone could shed some light into that. I'm mostly curious if it's not using hardware acceleration when I switch it to GCM.

[โ€“] anzo@programming.dev 2 points 2 months ago

The week went by and this was left unanswered. Usually I research a bit to treat anything on these threads. This time, I'm on the phone, so I went lazy and directly to chatgpt. Hopefully this is not an AI hallucination and it sheds some light for you.

The performance difference you're observing between AES128-CTR and AES128-GCM in OpenSSH with X11 forwarding can be attributed to several factors, including the nature of the ciphers and hardware acceleration support.

AES128-CTR vs AES128-GCM

  1. Cipher Characteristics:

    • AES128-CTR (Counter Mode): This mode turns a block cipher into a stream cipher. It is generally faster because it can be parallelized and does not require padding.
    • AES128-GCM (Galois/Counter Mode): This mode provides both encryption and authentication (integrity check). The additional authentication step can introduce overhead, making it slower compared to CTR mode.
  2. Hardware Acceleration:

    • AES-NI Support: Modern CPUs support AES-NI (Advanced Encryption Standard New Instructions), which accelerates AES operations. Both CTR and GCM modes can benefit from AES-NI, but the extent of the acceleration can vary.
    • GCM Overhead: Even with hardware acceleration, GCM mode has additional computational overhead due to the authentication process. If the hardware acceleration is not fully utilized or if the implementation is suboptimal, this overhead can become more pronounced.

Checking Hardware Acceleration

To determine if your system is using hardware acceleration for AES operations, you can check the following:

  1. CPU Support:

    • Verify if your CPU supports AES-NI by checking the CPU flags:
      grep aes /proc/cpuinfo
      
    • If you see aes in the output, your CPU supports AES-NI.
  2. OpenSSL Benchmark:

    • Run an OpenSSL benchmark to see the performance difference between CTR and GCM modes:
      openssl speed -evp aes-128-ctr
      openssl speed -evp aes-128-gcm
      
    • Compare the results to see if there's a significant difference in performance.
  3. SSH Configuration:

    • Ensure that your OpenSSH configuration is optimized for hardware acceleration. You can specify the ciphers in your SSH configuration file (/etc/ssh/sshd_config for the server and /etc/ssh/ssh_config or ~/.ssh/config for the client):
      Ciphers aes128-ctr,aes128-gcm@openssh.com
      
    • Restart the SSH service after making changes:
      sudo systemctl restart ssh
      

Conclusion

The performance difference between AES128-CTR and AES128-GCM is expected due to the additional authentication overhead in GCM mode. Ensuring that your system is utilizing hardware acceleration (AES-NI) can help mitigate some of this overhead, but GCM will generally still be slower than CTR. If performance is critical and you do not need the additional authentication provided by GCM, sticking with CTR mode might be the better option.