some questions on OpenSSH alogs

[Christian Weisgerber]

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