search

fpoirotte / pssht

SSH server written in PHP
https://pssht.readthedocs.io
MIT License
40 stars 9 forks source link

Support AEAD_AES_128_GCM and AEAD_AES_256_GCM #16

Open fpoirotte opened 9 years ago

fpoirotte commented 9 years ago

Follow-up ticket for issue #3.

The official names for aes128-gcm & aes256-gcm as registered to IANA (https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml) are:

These names are registered both as cipher & MAC algorithms.

Although Pssht now supports these algorithms, it does so under private names (aes128-gcm@openssh.com and aes256-gcm@openssh.com, which are both compatible with OpenSSH's implementation/behaviour).

This is necessary to avoid issues in RFC 5647. More specifically, section 5.1 of the RFC states that:

   If AES-GCM is selected as the encryption algorithm for a given
   tunnel, AES-GCM MUST also be selected as the Message Authentication
   Code (MAC) algorithm.  Conversely, if AES-GCM is selected as the MAC
   algorithm, it MUST also be selected as the encryption algorithm.

However, it fails to specify the behaviour when AES-GCM is presented for both encryption & MAC using different variants (say the cipher presented is AEAD_AES_128_GCM but the MAC is AEAD_AES_256_GCM).

The purpose of this ticket is to add support for the official names. The implementation will raise an error and close the connection whenever conflicting algorithms would otherwise be selected. This way, interoperability with other implementations conforming to RFC 5647 can be kept.

kikones34 commented 3 years ago

Hello, sorry for posting this here, I know it is not very appropriate, but I can't find any other reliable way to contact you. You mention in the end "This way, interoperability with other implementations conforming to RFC 5647 can be kept". Do you happen to know of such an implementation? I have been trying to find one, but virtually all SSH implementations I find only implement the OpenSSH version of AES-GCM.

fpoirotte commented 3 years ago

Hi,

I've not met such implementations in the wild, but a quick look around brought the following:

Regards, François

kikones34 commented 3 years ago

Hi François, I had not stumbled upon the Erlang implementation of SSH. After a bit of tinkering I managed to make it use AEAD_AES_256_GCM. This is exactly what I was looking for, thank you very much!

gicelessh2 commented 1 year ago

hi, I have one simple doubt AEAD_AES128_gcm and AES_128_gcm is the same cipher? Is it just the name different in iana and rfc?

ecki commented 6 months ago

hi, I have one simple doubt AEAD_AES128_gcm and AES_128_gcm is the same cipher? Is it just the name different in iana and rfc?

Whoever at IANA who thought it would be a good idea to break with Kebap-case convention deserves to look at their registry the whole day. Anyway, it looks to me like aes128-gcm@openssh.com and AEAD_AES_128_GCM use the same cryptographic constructs, in fact the OpenSSH PROTOCOL extension explicitely cites only RFC5647, mentioning the only difference is the cipher/mac semantic (which is much clearer for the OpenSSH variant)

I consider it a feature not advertising it by default

ecki commented 6 months ago

I find only implement the OpenSSH version of AES-GCM.

leaving the link here since it’s impressive and I just found it: https://ssh-comparison.quendi.de/comparison/cipher.html

fpoirotte commented 6 months ago

hi, I have one simple doubt AEAD_AES128_gcm and AES_128_gcm is the same cipher? Is it just the name different in iana and rfc?

Whoever at IANA who thought it would be a good idea to break with Kebap-case convention deserves to look at their registry the whole day. Anyway, it looks to me like aes128-gcm@openssh.com and AEAD_AES_128_GCM use the same cryptographic constructs, in fact the OpenSSH PROTOCOL extension explicitely cites only RFC5647, mentioning the only difference is the cipher/mac semantic (which is much clearer for the OpenSSH variant)

I consider it a feature not advertising it by default

TL;DR: yes, both AEAD_AES_128_GCM and aes128-gcm@openssh.com use the same cipher (AES with a 128-bit key) and construct (Galois-Counter Mode, aka. GCM). As you noted, they are identical, except in their semantic.

Long story:

For historical reasons, SSH distinguishes between algorithms used for Encryption (Ciphers) and algorithms used for Authentication (MACs). Both types of algorithmes are necessary to establish a secure connection (one ensures data privacy, while the other ensures message integrity).

Being a modern algorithm, AES-GCM provides what's known as Authenticated Encryption with Additional Data (AEAD). That is, although AES-GCM is considered a cipher algorithm, it also provides authentication features similar to MAC algorithms. Therefore, when AES-GCM is used, there is no need for a separate MAC algorithm.

However, this resulted in an ambiguity in RFC 5647. The RFC basically says that AES-GCM variants can be listed either as ciphers or MAC algorithms, and that when they appear in a list, values in the other list must be ignored. What it fails to specify is how to handle situations where different variants of AES-GCM appear in both lists, e.g. AEAD_AES128_gcm is listed in the ciphers and AEAD_AES256_gcm is listed in the MACs.

In this case, should we use AEAD_AES128_gcm (ignoring the values in the MACs list) or should we use AEAD_AES256_gcm (ignoring the values in the ciphers) instead? An implementation may choose either solution, creating incompatibilities.

Another similar problem arises if the client advertises support for AEAD_AES128_gcm in its cipher list while the server advertises the same algorithm in its MAC list: it's unclear in this case whether both the client and server will be able to negotiate this algorithm (assuming it was the given the highest priority in both lists) or if they will fail to notice this common algorithm (and instead settle for another set of algorithms, or fail entirely). Most likely, the algorithm would not count as a common algorithm in this case.

The OpenSSH extension solves these problems by specifying that aes128-gcm@openssh.com (and the 192 & 256-bit variants) can only be listed as a cipher, and never as a MAC algorithm.