some questions on OpenSSH alogs

[Christoph Anton Mitterer]

Hey folks

I'd have some questions on algos in OpenSSH,... perhaps one of you can
shed a bit light.... not sure if I'm still up-to-date everywhere in 
cryptology,... but I read Damien's nice blog post[0]

I usually want to use the most securest algos and I don't particularly
look at much backwards compatibility for older clients. Neither do I
care a lot about speed.

Actually I think others may be interested in this, too, and one could
publish it in the end in a blog or so.



I) Ciphers
3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc at lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm at openssh.com
aes256-gcm at openssh.com
chacha20-poly1305 at openssh.com

Okay we can drop 3des and arcfour for security, that's clear. And I'd
also have my doubts about blowfish and cast128, right?!
Apparently the CBC versions are all insecure (at least as used in ssh)
now?

So we remain with:
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm at openssh.com
aes256-gcm at openssh.com
chacha20-poly1305 at openssh.com

1) I understand that only the later 3 use authenticating encryption,...
does this mean thought that aes*-ctr are generally less secure? Or are
they secure again in combination with the right MAC?
Cause I may actually need to still enable these three for older clients
at the university.

2) Regarding the AES with GCM (and also with all other algos, not only
Ciphers but MACs and so on)... why do you always default to using the
versions with the smaller block size?

3) Now chacha20/poly1305... it's fairly new and apart from the fact that
it allows you to encrypt the packet sizes again... can one consider it
to be at least as secure as the aes*-ctr modes?
Or is e.g. aes256-ctr + an EtM MAC mode a more secure choice?
AFAIU, Poly1305-AES is basically as secure as AES. I haven't much
knowledge on the security of ChaCha20,... there seem to be some first
attack trials though
(https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant).

4) Oh and btw: When an authenticating encryption Cipher is used... do
the MACs (directive) still play a role? In the sense, does SSH even
calculate MACs then?

5) Wouldn't (note the changed ordering of block sizes 256/192/128):
chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
or perhaps even just:
chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com
be a safer default then the current:
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com
?




II) MACs
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160 at openssh.com
umac-64 at openssh.com
umac-128 at openssh.com
hmac-sha1-etm at openssh.com
hmac-sha1-96-etm at openssh.com
hmac-sha2-256-etm at openssh.com
hmac-sha2-512-etm at openssh.com
hmac-md5-etm at openssh.com
hmac-md5-96-etm at openssh.com
hmac-ripemd160-etm at openssh.com
umac-64-etm at openssh.com
umac-128-etm at openssh.com

I'm so bold an remove anything MD5, SHA1 and ripemd160 based (yeah, I
know that HMACs aren't so strongly affected by collisions in their
underlying hash algos as those themselves, but nevertheless).

Next one would probably want to remove all non EtM modes, right, or is
there any cipher combination left in which they can be used securely?
So one would be left back with:
hmac-sha2-256-etm at openssh.com
hmac-sha2-512-etm at openssh.com
umac-64-etm at openssh.com
umac-128-etm at openssh.com

6) So how does the security of HMAC compare to UMAC? I couldn't really
find much about this.

7) I found however, that UMAC is optimised for 32bit architectures...
are there any plans to integrate a VMAC algo?

8) Wouldn't (note the changed ordering of block sizes 512/256
respectively 128/64):
umac-128-etm at openssh.com,umac-64-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com
be a safer default then the current:
umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512
?




III) Key Exchange Alogs
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256 at libssh.org

Okay I haven't much clue here... I'd again drop sha1 based stuff.
Perhaps one cannot trust the NIST curves (but can one trust SHA2 then?)
so I'd definitely prefer DJBs curve when it comes to ECC.

9) Which of them do provide (perfect) forward secrecy?

10) What's the difference between the DH group and the group-exchange
ones?

11) How would one order them based on security?
I'd probably go for: 
curve25519-sha256 at libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,
maybe also just:
curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256
or even just:
curve25519-sha256 at libssh.org
At least assuming that Curve 25519 is used with ECDH, therefore also
having PFS.




IV) HostKeyAlgorithms
Actually I'm a bit unsure what these actually mean shouldn't those
depend on the used KEx? I.e. that e.g. ssh-ed25519 can only be used with
KEx=curve25519-sha256 at libssh.org?

We have in total these:
ssh-ed25519
ssh-ed25519-cert-v01 at openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01 at openssh.com
ssh-dss-cert-v01 at openssh.com
ecdsa-sha2-nistp256-cert-v01 at openssh.com
ecdsa-sha2-nistp384-cert-v01 at openssh.com
ecdsa-sha2-nistp521-cert-v01 at openssh.com
ssh-rsa-cert-v00 at openssh.com
ssh-dss-cert-v00 at openssh.com

I'd drop dss, due to the key size limitations.

I'd guess the -cert-v* algos are the ones for SSH Certificate
Authentication... and AFAIU this is not more or less secure than the use
of traditional SSH keys, just that you have the certificate based way of
"replacing" known_hosts and authorized keys.
So I let them in, with the exception of cert-v00? What's the matter with
them?

As for the NIST curves the same goes as above.

So one ends up with:
ssh-ed25519
ssh-ed25519-cert-v01 at openssh.com
ssh-rsa
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01 at openssh.com
ecdsa-sha2-nistp256-cert-v01 at openssh.com
ecdsa-sha2-nistp384-cert-v01 at openssh.com
ecdsa-sha2-nistp521-cert-v01 at openssh.com

Since I distrust NIST, I'd probably choose this (note the changed
ordering of block sizes 256/192/128): 
ssh-ed25519,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa,ssh-rsa-cert-v01 at openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01 at openssh.com
or really just:
ssh-ed25519,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa,ssh-rsa-cert-v01 at openssh.com

Wouldn't that be a better default then the current:
ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com,
ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,
ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss

I especially do not understand why you sort the cert algos before their
"normal" counterparts" and why the NIST curves come before ED25519,
while KexAlgorithms already haves the curve25519 at first.

The manpage says "If hostkeys are known for the destination host then
this default is modified to prefer their algorithms."
But does that mean it modifies the ordering, even when I manually set
something?



Cheers,
Chris.



[0] http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20141018/78a5aaa5/attachment-0001.bin>