kex: allow SNTRU-Prime

[brxken128]

This PR adds the SNTRU-Prime key exchange, and adds ChaCha20-Poly1305 back as a symmetric algorithm.

#7 (arguably incorrectly) removed ChaCha20-Poly1305 from the approved ciphers. It is an AEAD, similar in function to AES-GCM, however it is likely more secure in the grand scheme of things and isn't vulnerable to the Terrapin attack. This blog post mentions some of the shortcomings of AES-GCM, but more importantly highlights some of the benefits for (X)ChaCha20-Poly1305. XChaCha has the advantage of a 192-bit nonce, but the base ChaCha is not too far off.

SNTRU-Prime is a lattice-based post-quantum key exchange and aims to patch some of the shortcomings with current key exchanges, going into the post-quantum era. In the OpenSSH implementation, it's used in hybrid mode with x25519 - this way, if one fails (whether that's SNTRU-Prime or x25519), the other will likely still hold up.

[IceCodeNew]

I think you are making a point here. I do agree AES-GCM sucks, and if it is not for migrating the Terrapin attack, I always preferred ChaCha20-Poly1305 rather than AES-GCM.
Though, I still got to put my two cents in.

1. The article you referred to, is about how AES-GCM sucks, not how AES-GCM failed to do its work. If there is a reason that makes ChaCha20-Poly1305 not an available option FOR NOW, switching to AES-GCM is a sound decision.
2. You said ChaCha20-Poly1305 is not vulnerable to the Terrapin attack. Would you please give more details about it? I only got information that says the opposite [1]
3. Please give the information like from which version of OpenSSH it supports the SNTRU-Prime key exchange. It must not be neglected to find a balance between compatibility and cool new features.

[1]:

In practice, our attack can be applied against any connection using either ChaCha20-Poly1305 or any CBC-mode cipher in combination with the Encrypt-then-MAC paradigm.

https://terrapin-attack.com/
In the section Who is vulnerable?

[brxken128]

OpenSSH 9.0 and later supports SNTRU-Prime (source), although I did misread about the ChaCha20-Poly1305 being involved in the Terrapin vulnerability so I'll remove that from the PR.

[IceCodeNew]

OpenSSH 9.0 is not yet available for the latest LTS version of Ubuntu. I believe the proper time for this PR would be around 2025-2026 when the old stable release of Debian or Ubuntu has supported SNTRU-Prime.
However, that is out of courtesy to others, I myself would get this change into my fork ASAP ;-)

[brxken128]

OpenSSH 9.0 is not yet available for the latest LTS version of Ubuntu. I believe the proper time for this PR would be around 2025-2026 when the old stable release of Debian or Ubuntu has supported SNTRU-Prime. However, that is out of courtesy to others, I myself would get this change into my fork ASAP ;-)

I believe it's fine, the connection should just automatically fall back to one of the other algorithms, but the additional security for users who do have OpenSSH 9.0+ would greatly reduce the risk of "harvest now, decrypt later".

[IceCodeNew]

I believe it's fine, the connection should just automatically fall back to one of the other algorithms, but the additional security for users who do have OpenSSH 9.0+ would greatly reduce the risk of "harvest now, decrypt later".

How about arranging it to the beginning?

[k4yt3x]

It seems the issue with Chacha20-Poly1305 has been addressed so I'll only focus on the KEX here.

Given that the "newer & better" post-quantum KEX algorithm may be preferred, I'd concur that we move it to the top of the list to give it a higher priority. While reviewing the KexAlgorithms I also realized that all the ecdh-sha2 algorithms are missing and I can't quite remember why they were removed at the first place. I did some searches and can't confirm they have known weaknesses and vulnerabilities, so I'm putting it back. Let me know if you know any shortcomings of the ECDH suites.

The complete list looks something like this:

1. sntrup761x25519-sha512@openssh.com
2. curve25519-sha256
3. curve25519-sha256@libssh.org
4. ecdh-sha2-nistp521
5. ecdh-sha2-nistp384
6. ecdh-sha2-nistp256
7. diffie-hellman-group16-sha512
8. diffie-hellman-group18-sha512
9. diffie-hellman-group14-sha256

Let me know what you think of this. @brxken128 @IceCodeNew

Also thanks for the PR. I didn't know this new algo came out.

[brxken128]

The complete list looks something like this:

1. `sntrup761x25519-sha512@openssh.com`
2. `curve25519-sha256`
3. `curve25519-sha256@libssh.org`
4. `ecdh-sha2-nistp521`
5. `ecdh-sha2-nistp384`
6. `ecdh-sha2-nistp256`
7. `diffie-hellman-group16-sha512`
8. `diffie-hellman-group18-sha512`
9. `diffie-hellman-group14-sha256`

That looks pretty solid to me! Hybrid PQ for setups that can take advantage of it > curve25519 > the NIST curves > FFDHE(s) - this is the exact order I'd have selected as well. I would raise diffie-hellman-group18-sha512 one level though - it uses an 8192-bit prime, as opposed to group-16's 4096 bits. We could additionally include group-17 between the two, as it uses a 6144-bit prime (source for all of group definitions: RFC3526).

The 2048-bit prime used by the group 14 variant raises concerns about its long-term security, especially given recent advancements in discrete logarithm solving. This doesn't necessarily mean immediate compromise of course, but I think it's definitely a risk to consider.

Group 16 and 16 use larger primes, so they can probably stay in order to support the rare (but not unheard of) extremely outdated configurations, but I personally believe that group 14 should be removed.

Most deployments, especially modern ones, will almost certainly support at least some of the stronger algorithms higher up in the chain (whether that's curve25519, the NIST curves, or even one of the other FFDHE groups that use a larger prime). If all else fails, I'd much rather see an error message alerting me that no secure key exchanges are available than unknowingly use a weak/insecure connection.

I'd love to hear your thoughts - these are just my two cents and you may have another angle that I've yet to consider!

Again, I must apologise regarding the original ChaCha20 inclusion; I completely misread the Terrapin details and should have double checked - thank you for the correction.

I'll wait for a response before changing this PR so that we're both/all on the same page!

[k4yt3x]

I agree 2048 bits is a bit too small in this day and age. The full revised list will be:

1. sntrup761x25519-sha512@openssh.com
2. curve25519-sha256
3. curve25519-sha256@libssh.org
4. ecdh-sha2-nistp521
5. ecdh-sha2-nistp384
6. ecdh-sha2-nistp256
7. diffie-hellman-group18-sha512
8. diffie-hellman-group17-sha512
9. diffie-hellman-group16-sha512

...or in sshd_config:

KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group18-sha512,diffie-hellman-group17-sha512,diffie-hellman-group16-sha512

This looks sound to me. I'll await @IceCodeNew's input.

[IceCodeNew]

@k4yt3x

I also realized that all the ecdh-sha2 algorithms are missing and I can't quite remember why they were removed at the first place. I did some searches and can't confirm they have known weaknesses and vulnerabilities, so I'm putting it back. Let me know if you know any shortcomings of the ECDH suites.

There is a reason for removing those algorithms, not for vulnerabilities of the ECDH suites, but for serious misgivings about the very design in the NIST P-curves.

Refer to: jtesta/ssh-audit#213 (comment)

Disabling the P-curves does not impact compatibility whatsoever, as all modern SSH clients support X25519. In fact, OpenSSH's default key exchange has been X25519 since 2014.
Given the strong suspicions, as well as the fact that more modern alternatives are already well-supported says (to me, anyway) that its time for the world to move on from the NIST P-curves.

To put my two cents in, I prefer to remove the following Kex algorithms:

• ecdh-sha2-nistp521
• ecdh-sha2-nistp384
• ecdh-sha2-nistp256

[k4yt3x]

Ah yes thanks @IceCodeNew. There's got to be a reason why they were originally excluded. I just couldn't remember. I'd agree with removing the NIST P-curves. In addition, perhaps add some comments so this is documented. @brxken128 do you wanna go ahead and update the PR?

[IceCodeNew]

I just found out that the KEX algorithm "diffie-hellman-group17-sha512" is not supported by https://github.com/rapier1/hpn-ssh . It might also break on other implementations.
@k4yt3x @brxken128

# /usr/sbin/hpnsshd
Unsupported KEX algorithm "diffie-hellman-group17-sha512"
/etc/hpnssh/sshd_config.d/01-harden-by-icn.conf line 107: Bad SSH2 KexAlgorithms 'sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group18-sha512,diffie-hellman-group17-sha512,diffie-hellman-group16-sha512'.

[k4yt3x]

There hasn't be any activity from @brxken128. Given this is a security patch I'd like to not stall it for too long, so I'll go ahead and edit the commits. Given what we have discussed, I believe this is the list of algos that should be used:

1. sntrup761x25519-sha512@openssh.com
2. curve25519-sha256
3. curve25519-sha256@libssh.org
4. diffie-hellman-group18-sha512
5. diffie-hellman-group16-sha512

If something isn't right we can reopen or create a new issue.

[brxken128]

I apologise for the lack of a response, and thank you for making the changes and finishing the PR off. I'm glad I could help and improve this config regardless - I've personally adopted it on all of my SSH servers and I feel better knowing that everything is well thought out and in good hands!