LWN: Comments on "OpenSSH 7.0"

OpenSSH 7.0

gerv — Mon, 24 Aug 2015 12:14:18 +0000

Actually, there's only _one_ now, and we are trying to removing that one too: https://bugzilla.mozilla.org/show_bug.cgi?id=1156844 . But there's not much you can do, except wait, if lots of websites keep using certs chaining to it.

Gerv

OpenSSH 7.0

jwilk — Thu, 13 Aug 2015 09:39:50 +0000

> Except commercial CAs never used 1024-bit RSA keys

They did. In fact, there are still 1024-bit RSA keys in the Mozilla CA store.

generating keys

malor — Thu, 13 Aug 2015 00:32:34 +0000

There are no guarantees. But, as far as we know, 4096-bit RSA should last that long. You can generate one this way:

ssh-keygen -t rsa -b 4096 -o

(the -o tells it to encrypt the file with a newer, stronger algorithm, making it harder to bruteforce the passphrase.)

The Curve25519 keys are about equivalent to 3072-bit RSA keys, and can be generated like this:

ssh-keygen -t ed25519

The resulting keys are quite short, only 32 bytes, and they generate almost instantly. There are no other options: all ed25519 keys are 256-bit, and all are stored with the better encryption.

If you want to force your ssh servers to use Curve25519 encryption only, you can do so with these lines:

Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org

This explicitly turns off all other encryption. I'm not sure the MAC line actually does anything: someone commented that there's a MAC built into Curve25519 encryption already. So that line may be superfluous.

You can put the same lines in ssh_config, as well, if you want to force those options on all outgoing connections.

This is a very fast algorithm, and will run very well even on weak CPUs. On a modern Intel processor with the AES New Instructions, hardware-accelerated AES is faster than Curve25519, which might be an issue if you're driving extreme bandwidth. Most processors with AESNI should still be able to saturate a gigabit with Curve25519, but an unusually weak CPU or unusually large bandwidth demands might make hardware-accelerated AES more attractive.

Perhaps foolishly, the biggest reason I trust Curve25519 was because the NIST had nothing whatsoever to do with it: after the DUAL_EC random number generator debacle (it was deliberately compromised by the NSA, who then bribed the RSA company to make it their default RNG), I'd rather use encryption standards that the American government has nothing whatsoever to do with.

OpenSSH 7.0

malor — Thu, 13 Aug 2015 00:18:57 +0000

Use ChaCha20/Poly1305. It runs fine on the Pi.... the bottleneck there will be either the USB storage or the 100MBit Ethernet, so if a cipher can go twice that fast (25Mbit/sec), that should be adequate to keep the wire saturated.

The person at ImperialViolet benched an ARM7 CPU at about 90Mbyte/sec. Even a Pi 1 would probably be able to do half that. A Pi 2 would probably be loping at the 12.5Mbyte maximum data rate the platform can handle.

generating keys

nix — Wed, 12 Aug 2015 15:40:53 +0000

That requires knowing what cryptographic breaks will happen in the next ten years. If you have a crystal ball that clear, there are a lot of other interesting things you can do with it too :)

OpenSSH 7.0

nix — Wed, 12 Aug 2015 15:40:10 +0000

ssh -oHostKeyAlgorithms=+ssh-dss -i .ssh/my_dsa_key host

is what you want.

If it was just a -i away, the algorithm wouldn't be disabled in any sense that I can see.

generating keys

glen — Wed, 12 Aug 2015 11:45:40 +0000

so what would be ssh-keygen arguments to generate new key that would be working now and considered safe/secure in ten years?

OpenSSH 7.0

Otus — Wed, 12 Aug 2015 07:23:56 +0000

> 1024-bit Diffie-Hellman keys are really only a practical concern when using a well-known prime group (i.e. prime plus generator).

I still think it's easier to just use a well known 2048-bit group (group 14), and that protects you from both targeted and untargeted attacks.

> So notwithstanding the greater strength of ECC, it also makes users easier targets in this respect.

But the solution is easy: just use a larger curve. A factor of 2^x in curve size is ~equivalent to having 2^(x/2) unique user defined curves instead. If 160-bit ECC is roughly equivalent to 1024-bit DH, you can step up to 256-bit ECC and be more secure than with a realistic amount of different curves. That's faster, with a good implementation, and has way smaller keys and messages.

Yes, you need to trust the curve, but there are a bunch of curves from independent parties now.

OpenSSH 7.0

arekm — Wed, 12 Aug 2015 06:35:53 +0000

Looks now client side keys are ignored unless are matching PubkeyAcceptedKeyTypes.

Too bad that even explictly telling ssh client to use specific key doesn't work (without PubkeyAcceptedKeyTypes matching) like:
ssh -i .ssh/my_dsa_key host

:-/

OpenSSH 7.0

wahern — Wed, 12 Aug 2015 03:34:02 +0000

1024-bit Diffie-Hellman keys are really only a practical concern when using a well-known prime group (i.e. prime plus generator). Once upon a time protocols and implementations only used well-known prime groups because of suspicions about accidentally generating weak primes. These prime groups were (and largely still are) identical across all users of the software, and so by attacking a single prime group you could snoop on all users of that software, or at least a substantial fraction of them a substantial amount of the time. It's analogous to certificate authorities, where cracking the CA's key effects the security of everybody downstream. Except commercial CAs never used 1024-bit RSA keys, and cracking their signing key only permits man-in-the-middle attacks, whereas breaking a DH prime group let's you record and decrypt the conversation, regardless of the presence of ephemeral DH private keys.

But today it's no longer considered poor practice to generate prime groups dynamically. Still, generation of safe primes can take an appreciable amount of time even on modern hardware. Compare the running time of

$ openssl dhparam 1024

$ openssl genrsa 1024

(You may have to run the former multiple times if you, per chance, found one more quickly than usual.)

Generating the parameters dynamically causes headaches because of the possibly very long initial startup time and general logistical issues of doing it in-process. Most software on both the server and client side just doesn't know how to dynamically generate DH groups, even for ephemeral DH. This is especially true for embedded and appliance systems. This is why over the years there have been security issues with compromised DH parameters, such as when software projects or vendors generated parameters on systems with broken a PRNG, effecting everybody downstream.

But they all usually allow you to specify your own at startup. If you can't switch to ECDH, there's nothing wrong with generating your own random 1024-bit DH parameters. I seriously doubt the NSA will expend the same effort to crack a key used by one person the same as one shared by millions of people. Of course, 2048-bit would be even better. 1024-bit has stuck around for so long because in the 2000s there was still plenty of software which only worked with key sizes <= 1024 bits. But I can't imagine a randomly generated 1024-bit DH prime group being the weakest link in a targeted attack. Most people don't even have a hardware RNG. (It's a real shame Soekris doesn't provide their crypto accelerator in mini PCI express form; it's been useless for accelerating anything for years, but it sported the cheapest and most widely supported hardware RNG.)

With ECDH protocols you _must_ use shared curves (equivalent to shared prime groups for DH). You can't generate random ones, for various technical and functional reasons. So notwithstanding the greater strength of ECC, it also makes users easier targets in this respect. Which is perhaps why some people are very suspicious about the NIST-standardized curves.

OpenSSH 7.0

stqn — Tue, 11 Aug 2015 19:56:59 +0000

I’m not sure that the use case is so "niche", given the popularity of the Raspberry Pi and NAS boxes nowadays. Also installing NFS is not "minor extra effort". And of course any Linux user knows that using an old version is neither convenient nor recommended, if at all possible.

OpenSSH 7.0

jhoblitt — Tue, 11 Aug 2015 19:18:18 +0000

Actually, my statement about about EL is incorrect -- my memory must be really going. RHEL appears to have never included hpn-ssh. Scientific Linux (SL) 4 definitely included hpn-ssh patches. I thought SL 5/6 had as well but it looks like not.

OpenSSH 7.0

jhoblitt — Tue, 11 Aug 2015 19:01:33 +0000

I believe that patches for "null" or "none" ciphers ssh were popular about a decade ago. "hpn-ssh" may have been the most popular patch set. EL5 & EL6 both included hpn patches.

http://www.psc.edu/index.php/hpn-ssh

My recollection, which may be faulty, is that is that the "none" cipher didn't make much of a difference below a few 100 mbit/s.

OpenSSH 7.0

jtaylor — Tue, 11 Aug 2015 16:43:48 +0000

As you are happy with weak crypto I assume the fileserver is not on the public net.
So the solution is simple: just use an older version of ssh or don't update whatever you have now.

Requiring some minor extra effort for niche use cases is in my opinion preferable than risking everyone else due to the possibility of misconfiguration or higher attack surface.

OpenSSH 7.0

ibukanov — Tue, 11 Aug 2015 16:31:08 +0000

> a very weak Atom CPU

Intel started to put AES instructions into Atoms since Q3 2013. If you have one of those, then aes128-gcm@openssh.com should be the fastest cipher.

OpenSSH 7.0

bgmarete — Tue, 11 Aug 2015 16:25:15 +0000

Chacha20-Poly1305 is what you are looking for. If it can do 95MB/s on a phone-class ARM cpu, I am sure your Atom can run it fast enough. See: https://www.imperialviolet.org/2013/10/07/chacha20.html

OpenSSH 7.0

mordocai — Tue, 11 Aug 2015 15:32:07 +0000

If you are worried about resource usage you really shouldn't be using sshfs, with or without encryption. NFS/Samba may be harder to setup, but in my experience are much more efficient than any setup you can achieve with sshfs. I'd strongly recommend just learning NFS(or samba if you need to play nice with windows). The hardest part isn't the setup, but tweaking the configuration params to be optimal.

OpenSSH 7.0

stqn — Tue, 11 Aug 2015 15:20:40 +0000

I am using sshfs with arcfour and/or blowfish-cbc on my local network in order to have the smallest possible load on my file server, which is running a very weak Atom CPU. If it was possible to use ssh with no encryption I would do it instead, but unfortunately it is not.

Sshfs is very easy to setup and use, unlike nfs or samba... So I hope they reconsider the deletion of weaker algorithms.

It is my understanding that the new Raspberry Pi 2 is also relatively slow for encryption, so it is not only "old" computers that would be affected.

OpenSSH 7.0

Otus — Tue, 11 Aug 2015 14:30:02 +0000

> Refusing all RSA keys smaller than 1024 bits (the current minimum is 768 bits)

Wow, long past time to refuse 768 bit keys, those could demonstrably be factored six years ago.

I don't think even 1024 should really be considered secure any more either: http://crypto.stackexchange.com/a/1982/13625

OpenSSH 7.0

mattdm — Tue, 11 Aug 2015 14:11:02 +0000

Finally, the PermitRootLogin option does what one might naively expect. Nice.