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@xxxxxxxxxx,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@xxxxxxxxxxx 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
