Prefer using 256-bit AEAD algorithms (CHACHA20_POLY1305, AES_256_GCM, AES_128_GCM), if possible, remove non-AEAD algorithms in the future. By the way, although AES_128_GCM key is shorter than AES_256_CTR, but it's AEAD, which is one of cipher supported in TLS 1.3, so prefer it rather than AES_256_CTR.
(In reply to tim from comment #0) > Prefer using 256-bit AEAD algorithms (CHACHA20_POLY1305, > AES_256_GCM, AES_128_GCM), if possible, remove non-AEAD algorithms > in the future. > By the way, although AES_128_GCM key is shorter than AES_256_CTR, > but it's AEAD, which is one of cipher supported in TLS 1.3, so > prefer it rather than AES_256_CTR.
Why? We do currently preference an AEAD cipher (chacha20-poly1305@openssh.com), but AES-GCM can be slower than AES-CTR. There are no known weaknesses in using CTR+MAC in the SSH protocol (cf. https://himsen.github.io/pdf/thesis.pdf)
Because some proxy provider, such as Psiphon, using AES_CTR_XXX_hmac-sha1 or AES_CTR_XXX_hmac-sha1-96, SHA_1 is weak. I think prefer using AEAD is a "defense in depth", because TLS 1.3 and Wireguard onld support AEAD, they are modern and widely used.
I do a test in OpenSSL, but it's in a Rocky Linux VM: openssl speed -evp aes-256-gcm Doing AES-256-GCM for 3s on 16 size blocks: 13327934 AES-256-GCM's in 2.94s Doing AES-256-GCM for 3s on 64 size blocks: 4010515 AES-256-GCM's in 2.96s Doing AES-256-GCM for 3s on 256 size blocks: 3382265 AES-256-GCM's in 2.97s Doing AES-256-GCM for 3s on 1024 size blocks: 942484 AES-256-GCM's in 2.96s Doing AES-256-GCM for 3s on 8192 size blocks: 122282 AES-256-GCM's in 2.97s Doing AES-256-GCM for 3s on 16384 size blocks: 61389 AES-256-GCM's in 2.98s version: 3.0.1 built on: Thu Aug 11 00:00:00 2022 UTC openssl speed -evp aes-256-ctr Doing AES-256-CTR for 3s on 16 size blocks: 15322101 AES-256-CTR's in 2.94s Doing AES-256-CTR for 3s on 64 size blocks: 4208151 AES-256-CTR's in 2.96s Doing AES-256-CTR for 3s on 256 size blocks: 3635130 AES-256-CTR's in 2.98s Doing AES-256-CTR for 3s on 1024 size blocks: 986443 AES-256-CTR's in 2.95s Doing AES-256-CTR for 3s on 8192 size blocks: 127640 AES-256-CTR's in 2.96s Doing AES-256-CTR for 3s on 16384 size blocks: 57412 AES-256-CTR's in 2.86s version: 3.0.1 built on: Thu Aug 11 00:00:00 2022 UTC AES_CGM doesn't much slower than AES_CTR
The collision weaknesses in SHA-1 are irrelevant for its use in HMAC and HMAC-SHA1 is not at all broken. I don't see any benefits to promoting AES-GCM to the front on the list. If new cryptanalysis that changes this, then we'll consider changing the ordering.
(In reply to tim from comment #4) > AES_CGM doesn't much slower than AES_CTR This varies a lot depending on the platform. For a counterexample (Ryzen 3900X), GCM is half the speed: $ openssl speed -evp aes-256-gcm Doing AES-256-GCM for 3s on 16 size blocks: 103804564 AES-256-GCM's in 2.99s Doing AES-256-GCM for 3s on 64 size blocks: 58949992 AES-256-GCM's in 2.99s Doing AES-256-GCM for 3s on 256 size blocks: 34661021 AES-256-GCM's in 3.00s Doing AES-256-GCM for 3s on 1024 size blocks: 11774310 AES-256-GCM's in 2.99s Doing AES-256-GCM for 3s on 8192 size blocks: 1690281 AES-256-GCM's in 2.99s Doing AES-256-GCM for 3s on 16384 size blocks: 853186 AES-256-GCM's in 3.00s $ openssl speed -evp aes-256-ctr Doing AES-256-CTR for 3s on 16 size blocks: 167022187 AES-256-CTR's in 2.99s Doing AES-256-CTR for 3s on 64 size blocks: 131872734 AES-256-CTR's in 3.00s Doing AES-256-CTR for 3s on 256 size blocks: 70440642 AES-256-CTR's in 2.99s Doing AES-256-CTR for 3s on 1024 size blocks: 23978238 AES-256-CTR's in 3.00s Doing AES-256-CTR for 3s on 8192 size blocks: 3358652 AES-256-CTR's in 2.99s Doing AES-256-CTR for 3s on 16384 size blocks: 1703078 AES-256-CTR's in 3.00s
Closing bugs from openssh-9.1 release cycle