some questions on OpenSSH alogs

[Christoph Anton Mitterer]

Hey Christian.

Thanks for your replies.

On Sat, 2014-10-18 at 22:22 +0000, Christian Weisgerber wrote: 
> 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.

I agree, well at least in parts:
IMHO the recent disasters only showed, how we are attacked on a broad
range - it doesn't prove anything, whether the crypto primitives
themselves are still secure. They might very well be, and we haven't
much prove that they wouldn't (well except some like TLS/SSL+RC4 or
SSLv3/CBC, etc.), but this alone doesn't guarantee they really still
are.
And any power who was really capable of breaking one of the stronger
crypto-primitives will likely handle that like a top-level state secret,
and only use in in rare circumstances,... so it's unlikely that we would
have gathered knowledge about this from e.g. Snowden.

Anyway, my point in they "securest algo" thingy is mostly this:
I cannot do much about exploits and security holes in software (which
can be used to avoid the crypto at all), neither about someone like the
NSA simply coming to my home and beating me up so severely till I give
them any password/key with pleasure... but when I have no
interoperability or performance issues, why shouldn't I increase the
crypto primitives to the strongest possible? :)


> You'll also find that OpenSSH 6.6 has already trimmed the list of
> default algorithms.
Sure,... but at work I've noticed that many people still use so old
clients, that they only have hmac-sha1 and -md5... :(


> > 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.
Mhh sure,... but is there any advantage (apart from performance and ease
of implementation), of using an AE cipher instead of an encrypting-only
cipher 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.
Sorry,.. of course...


> 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.
okay... I see,... regarding that I mostly go for the ECRYPT II and NIST
recommendations (http://www.keylength.com/en/3/)...
But especially when you want to go in the "Forseeable Future" range,...
it seems to be tough to actually do that with the current curves.

So for ED25519 and ECDH with the NIST curves... all the DH parameters
and sizes are fixed anyway, right?


> > 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.
Mhh that's basically my concern... right now I actually default to
Chacha20,... but as you said,... AES/GCM is probably much better
analysed... tough decision ;)


> > 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.
How important is the size there? I mean umac-128 and especially -64
sounds little in comparison to the hash sizes of e.g. sha2-512 with
HMAC. 


> > 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*
I see...

Well, let's hope it pays off, that people are high on DJB primitives ;) 


> "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)
Thanks,... even found that out later on myslef O;-)


> > 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.
So you said it uses SHA2 as well,... is there going to be an alternative
that uses Keccak? Or one which is, from the key size POV, more int eh
P521 range? 


> 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
So basically, when I don't have interoperability issues (people using
the v.00 certs) it's probably better to disable them. 


> > 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.

Okay,... now I get what it means... was on a completely different lead
(though hostkeys really means "non-certificate" keys here).



> 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.
Jup,... tightening my servers' TLS is probably the next thing to go
for,... unfortunately things seem to be a lot more confusing there.
Most of my services (apache, postfix, and that like) use OpenSSL,... one
has nothing (yet) like Curve25519 or Chacha2,...
OpenSSL also seems to have anonymous [EC]DH and non-ephemeral [EC]DH
cipher suites... so it's a bit tricky to determine to best cipher
selection string ;)
And it seems one mostly cannot configure the DH params... :(



Cheers & thanks,
Chris.
-------------- 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/20141019/e9245824/attachment-0001.bin>