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@xxxxxxxxxxxxxx aes128-ctr aes192-ctr aes256-ctr aes128-gcm@xxxxxxxxxxx aes256-gcm@xxxxxxxxxxx chacha20-poly1305@xxxxxxxxxxx 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@xxxxxxxxxxx aes256-gcm@xxxxxxxxxxx chacha20-poly1305@xxxxxxxxxxx 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@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx,aes128-gcm@xxxxxxxxxxx,aes256-ctr,aes192-ctr,aes128-ctr or perhaps even just: chacha20-poly1305@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx,aes128-gcm@xxxxxxxxxxx be a safer default then the current: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@xxxxxxxxxxx,aes256-gcm@xxxxxxxxxxx,chacha20-poly1305@xxxxxxxxxxx ? II) MACs hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 hmac-md5 hmac-md5-96 hmac-ripemd160 hmac-ripemd160@xxxxxxxxxxx umac-64@xxxxxxxxxxx umac-128@xxxxxxxxxxx hmac-sha1-etm@xxxxxxxxxxx hmac-sha1-96-etm@xxxxxxxxxxx hmac-sha2-256-etm@xxxxxxxxxxx hmac-sha2-512-etm@xxxxxxxxxxx hmac-md5-etm@xxxxxxxxxxx hmac-md5-96-etm@xxxxxxxxxxx hmac-ripemd160-etm@xxxxxxxxxxx umac-64-etm@xxxxxxxxxxx umac-128-etm@xxxxxxxxxxx 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@xxxxxxxxxxx hmac-sha2-512-etm@xxxxxxxxxxx umac-64-etm@xxxxxxxxxxx umac-128-etm@xxxxxxxxxxx 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@xxxxxxxxxxx,umac-64-etm@xxxxxxxxxxx,hmac-sha2-512-etm@xxxxxxxxxxx,hmac-sha2-256-etm@xxxxxxxxxxx be a safer default then the current: umac-64-etm@xxxxxxxxxxx,umac-128-etm@xxxxxxxxxxx,hmac-sha2-256-etm@xxxxxxxxxxx,hmac-sha2-512-etm@xxxxxxxxxxx,umac-64@xxxxxxxxxxx,umac-128@xxxxxxxxxxx,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@xxxxxxxxxx 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@xxxxxxxxxx,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256, maybe also just: curve25519-sha256@xxxxxxxxxx,diffie-hellman-group-exchange-sha256 or even just: curve25519-sha256@xxxxxxxxxx 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@xxxxxxxxxx? We have in total these: ssh-ed25519 ssh-ed25519-cert-v01@xxxxxxxxxxx ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01@xxxxxxxxxxx ssh-dss-cert-v01@xxxxxxxxxxx ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx ssh-rsa-cert-v00@xxxxxxxxxxx ssh-dss-cert-v00@xxxxxxxxxxx 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@xxxxxxxxxxx ssh-rsa ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01@xxxxxxxxxxx ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx 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@xxxxxxxxxxx,ssh-rsa,ssh-rsa-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx or really just: ssh-ed25519,ssh-ed25519-cert-v01@xxxxxxxxxxx,ssh-rsa,ssh-rsa-cert-v01@xxxxxxxxxxx Wouldn't that be a better default then the current: ecdsa-sha2-nistp256-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp384-cert-v01@xxxxxxxxxxx,ecdsa-sha2-nistp521-cert-v01@xxxxxxxxxxx,ssh-ed25519-cert-v01@xxxxxxxxxxx, ssh-rsa-cert-v01@xxxxxxxxxxx,ssh-dss-cert-v01@xxxxxxxxxxx,ssh-rsa-cert-v00@xxxxxxxxxxx,ssh-dss-cert-v00@xxxxxxxxxxx, 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
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
