thr3ads.net - openssh unix dev - some questions on OpenSSH alogs [Oct 2014]

If this information is useful, please help other people find it:
Share via:

Christoph Anton Mitterer

2014-Oct-18 16:35 UTC

some questions on OpenSSH alogs

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>

Christian Weisgerber

2014-Oct-18 22:22 UTC

head link

some questions on OpenSSH alogs

On 2014-10-18, Christoph Anton Mitterer <calestyo at scientia.net> wrote:
> 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=20
> cryptology,... but I read Damien's nice blog post[0]
Let me preface this with a remark: I think if there has been anything
to take away from the recent crypto disasters and spying revelations,
it's the confirmation that crypto systems are not exploited by
breaking cryptographic primitives.  Much of this "securest algo"
talk is armchair generalmanship that misses the point.

You'll also find that OpenSSH 6.6 has already trimmed the list of
default algorithms.
> 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?
They provide authenticated encryption in combination with a MAC.
> 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?
With the smaller _key_ size.  AES always has a 128-bit block size,
regardless of the key size.  AES-128 is good enough.  Larger key
sizes incur a performance cost.  There is also the issue of balancing
the various components of the overall system (KEX, keys, cipher,
MAC) so that they all have similar strength.
> 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?
For whatever it's worth, Chacha20 has received less scrutiny than
AES.  But see my remark at the beginning of this message.
> AFAIU, Poly1305-AES is basically as secure as AES.
Poly1305, U/VMAC, and GMAC all run the data through a noncryptographic
hash and encrypt the result with AES.
> 4) Oh and btw: When an authenticating encryption Cipher is used... do
> the MACs (directive) still play a role?
No.  Compare the ssh -v output:

debug1: kex: server->client aes128-ctr umac-64-etm at openssh.com none
debug1: kex: client->server aes128-ctr umac-64-etm at openssh.com none

debug1: kex: server->client aes128-gcm at openssh.com <implicit> none
debug1: kex: client->server aes128-gcm at openssh.com <implicit> none

(The fields are cipher, MAC, compression.)
> 6) So how does the security of HMAC compare to UMAC? I couldn't really
> find much about this.
Until somebody manages to break them, their strength is directly
related to the size of the tag.  For GMAC (AES-GCM) there has been
at least one paper on how truncating the MAC is bad, but we don't
do that.
> 7) I found however, that UMAC is optimised for 32bit architectures...
> are there any plans to integrate a VMAC algo?
I considered it, but decided I didn't want to further expand the
algorithm zoo we already have.  UMAC is plenty fast and the trend
is towards AEAD ciphers (authenticated encryption with associated
data) like AES-GCM or the Chacha20+Poly1305 construct.  VMAC could
be used to be build one; Chacha20+VMAC might have been interesting
and would have been faster than Chacha20+Poly1305, but everybody
is currently high on Daniel J. Bernstein's primitives, and while
U/VMAC are fast, they aren't pretty.  *shrug*
> III) Key Exchange Alogs
> 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.
There is no reason to distrust SHA2.  Even Ed25519 uses it.
> 9) Which of them do provide (perfect) forward secrecy?
All.
> 10) What's the difference between the DH group and the group-exchange
> ones?
"The original key agreement methods defined in the transport protocol use
 fixed, well-known groups for the Diffie-Hellman algorithm. This method
 allows a server to use a set of locally configured groups, and the
 client to request a preferred group size."  (RFC4419)
> 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-sha>
2-nistp256,diffie-hellman-group-exchange-sha256,
Strength-wise, Curse25519 compares to NIST-P256, so it depends how
you feel about the NIST curves.
> IV) HostKeyAlgorithms
> Actually I'm a bit unsure what these actually mean shouldn't those
> depend on the used KEx?
No, they are completely independent.
> 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 per the commit message:
  Revised certificate format ssh-{dss,rsa}-cert-v01 at openssh.com with the
  following changes:
  * Move the nonce field to the beginning of the certificate where it can
    better protect against chosen-prefix attacks on the signature hash
  * Rename "constraints" field to "critical options"
  * Add a new non-critical "extensions" field
  * Add a serial number
> 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.
I don't know.  I prefer Ed25519 keys, so I use (what a mouthful!)
-oHostKeyAlgorithms=ssh-ed25519 when connecting to a host for the
first time.
> 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?
If you connect to a host, the default server key type is
ecdsa-sha2-nistp256, and if you connect to a host for the first
time, that key will be saved in known_hosts.  However, if known_hosts
already contains a different type of key, that one will be chosen
instead.

I have ssh-ed25519 keys in my known_hosts file for all destination
hosts that support it, and this key will be picked to authenticate
the host (instead of ecdsa-sha2-nistp256).  No explicit setting of
HostKeyAlgorithms is required.
> [0] http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html
"Back in the dark ages of the SSH2 protocol's design, there wasn't
 consensus among cryptographers on the best order to apply encryption
 and authentication in protocols - in fact, the three main cryptographic
 protocols to emerge from the 1990s - SSL, SSH and IPsec - all use
 different choices"

So true.  IPsec got it right.  SSL got it wrong and that decision
keeps on giving, see this week's POODLE excitement.  SSH has gotten
better.

-- 
Christian "naddy" Weisgerber                          naddy at
mips.inka.de

openssh unix dev - Oct 2014 - some questions on OpenSSH alogs

some questions on OpenSSH alogs

some questions on OpenSSH alogs