You should stick with GCM over CTR

[jgunthorpe]

I like your article, but I noticed this.

Read your source material carefully (and I double checked this in source, see packet.c:packet_send2_wrapped):

Both AES-GCM and the EtM MAC modes have a small downside though: because we no longer desire to decrypt the packet as we go, the packet length must be transmitted in plaintext.

Using AES-CTR + hmac-sha2-512-etm over AES-GCM doesn't make any sense if the reason to reject GCM is the clear text packet length.

Further, if the two options are chacha20-poly1305 and AES-GCM (which are both AEAD algorithms) then openssh will never use a MAC algorithm at all, so that entire analysis could be dropped from the paper. For those two reasons I would stick with GCM.

It would also be good to include the signature hash algorithms in the authentication section.

DSA - signs with SHA-1
ECDSA - Uses SHA-256, SHA-384, SHA-512 depending on EC key length
Ed25519 - SHA-512
RSA - signs with SHA-1

Sadly, nobody on the openssh team has bumped up the hash algo used with RSA, the infrastructure is there to do it, it just hasn't been done..

I also think you should talk about the pedigree of the DJB algorithms vs the NIST algorithms. The suite of RSA + SHA-512 / DH / AES-GCM has been incredibly well studied at this point and the security is well understood. The DJB suite: Ed25519 + SHA-512 / ECDH / ChaCha20 + Poly1305 is state of the art and new. I like DJB, but it certainly hasn't had the analysis that the NIST suite has.

The DJB EC stuff is well studied but I'm not sure I'd substitute ChaCha for AES at this point. The main purpose of ChaCha20+Poly is speed, but if you are using new Intel hardware AES-GCM is much, much faster anyhow.

Cheers

[stribika]

The correct thing to do would be auth_enc(k1, length) || auth_enc(k2, data) for any construction of auth_enc. I think chacha20-poly1305 does this while AES-GCM, for some reason, processes everything together with length being the "additional data". I see this as the main advantage.

I'm not really obsessed with encrypting the sizes because when we wrap the whole thing in a hidden service, that should take care of any traffic analysis. However, together with this explicit recommendation against GCM for SSH http://fse2012.inria.fr/SLIDES/36.pdf I thought I should remove it. It doesn't make the compatibility any worse as far as I can tell.

If EtM works like GCM, meaning the length is only covered by "M", not "E", then I have the choice to disable CTR or to enable GCM. Disabling CTR is not worth it in my opinion. While this is not a compatibility focused article, having only chacha20 is not the best situation.

As for the NIST stuff, I have some hope for NIST P-521 because it's not listed as an unsafe curve on safecurves.cr.yp.to. It's not there at all (at least not by that name).

[jgunthorpe]

Most AEAD skip the second encrypt step, typically for performance. In most situations you can find the message boundaries implicitly anyhow (ie at segmentation boundaries + timing with TCP when using SSH, or at packet boundaries when using IPSEC/MACSEC). If you want to blind the message size you are better to send fixed size packets than try to obscure the lengths with another cipher instance.

Keeping aes-ctr + hmac-sha2-512 for compatibility with OpenSSH < 6.2 makes sense, but the choice of a modern cipher to use on current OpenSSH should be between chacha20-poly1305 and aes-gcm - that means gcm should be preferred for OpenSSH versions 6.2-6.5 before chacha is available, or if the user wishes to use the NIST suite not the DJB suite.

I thought the consensus was the Saarinen paper was overstating the risk? The analysis hasn't reduced the security bound of GHASH (see the fourth paragraph of the actual paper). I'm not sure why that power point singles out SSH, the paper does not, and ssh does not have attacker forced rekeying which seems to be necessary to make anything out of the weak key problem. Some IPSEC implementations would probably be more vulnerable to this than ssh...

[stribika]

RSA+SHA1 is a good catch. I think the only thing to do is to disable RSA. It's not even a hypothetical preimage on SHA1, collisions are enough here. I know RSA was studied a lot and I really wanted to leave it there.

[stribika]

No wait, a collision is not enogh. It's still bad.

[jgunthorpe]

The interesting thing about how SSH2 works is the that the RSA signature (using SHA-1) is computed over the output of the hash function used during the KeyExchange.

So for the diffie-hellman-group-exchange-sha256 authorized with rsa-sha1 the operations are:

Build the string from this:

  string    V_C, the client's identification string (CR and LF
            excluded)
  string    V_S, the server's identification string (CR and LF
            excluded)
  string    I_C, the payload of the client's SSH_MSG_KEXINIT
  string    I_S, the payload of the server's SSH_MSG_KEXINIT
  string    K_S, the host key
  mpint     e, exchange value sent by the client
  mpint     f, exchange value sent by the server
  mpint     K, the shared secret

Hash it using SHA-256

Hash the above 256 bits using SHA-1

Encrypt the above using the RSA public key

So it really isn't possible to attack the RSA SHA-1 in this context. All the values the server controls are fed through SHA-256 before being signed by RSA SHA-1. See RFC 4253 section 8.

Even with the older DH modes that use SHA-1 as the hash a collision would have to be generated within the above message format, an attacker cannot arbitrarily make the message longer. AFAIK that is still beyond the reach of any realtime attack on SHA-1 or even MD5.

Thus I'd think it is safe to leave RSA turned on.

[stribika]

It really doesn't look vulnerable, they have to attack the key exchange's hash. It doesn't work the other way though, having an SHA1 key exchange method then hashing that again with SHA2 actually doesn't add any security because SHA1 collisions will pass the same value to SHA2.

In fact, the second hash seems completely irrelevant. Why is it even there at all? Does SSH sign something else at some point?

[stribika]

So it looks like (auth2-pubkey.c) the client signs a SSH2_MSG_USERAUTH_REQUEST message with RSA+SHA1. This message contains the SHA2 hash from the key exchange and some other values. These other values all come from the already authenticated server so the only one who can attack SHA1 is the server itself. Such an attack would serve no purpose.

This also answers my previous question: the second hash is needed because it's input can be bigger than just the hash from the key exchange.

[jgunthorpe]

Not sure on the first hash, but my first guess would be it is to help keep the critical DH parameters secret. It would make a lot of sense to use a remote sign for the long lived server RSA key - ie have the unprivileged process that is doing the SSH connection setup call out to a more privileged process to do the sign operation. In that case it is better to send a hash than the critical parameters.

SSH2_MSG_USERAUTH_REQUEST has nothing to do with the HostKey parameter on the server (look for KEX messages instead), it is for client auth not server auth, though it would probably make sense to add a section to your paper discussing what crypto to use for authorized_keys and how to construct a good .ssh/identity*. Looks like the same comment applies.

[stribika-rdonly]

Yeah, I know it's one of the client auth choices. I was just looking for what else signs with SHA1 and if it's a problem or not.

I merged the server and client authentication together at the beginning because in my case, both are using the same public key algorithm. I have another ticket for supporting Google Authenticator and how to use authorized_keys so I will add more details.