Hacker News new | ask | show | jobs
by kiryin 1686 days ago
I belong to the camp that believes in using the defaults when it comes to ciphers. I am not an expert in cryptography, nor do I like copypasting stuff I don't fully understand. The openssh guys know this stuff better than I do and I think that's fine.
1 comments

I was long of that conviction too. But the default install optimizes for a different thing, compatibility. Or at least emphasizes is more than I would do.

For example I never use RSA keys. So these can go. Less cyphers => less attack surface.

But I do agree that I'm sure the defaults picked are sensible.

> ...For example I never use RSA keys.

Exactly, the default RSA for the keygen is what a lot of users accept without realizing the implications. Well, lots of HowTos out there suggest "enter, enter, enter.." to get your key.

What's the rationale for keeping RSA as a default these days?

> What's the rationale for keeping RSA as a default these days?

I think they recently changed this, but for the longest time RSA keys were the only kind AWS supported for EC2 keypairs.

For staff that weren't deploying EC2 instances, EC keys were fine, but for the ops people setting them up where the EC2 keypair was the initial access key, they needed RSA keys.

What? RSA keys are insecure?
I’m not an expert but I think RSA is discouraged these days because it’s strength is dependent on the key size which is regularly outdated as computers get faster/parallelize. Ten years ago a 512bit key was considered secure but these days I think 4096 is the recommended minimum length for a keypair that’s considered secure. Because of this it requires cycling through keys every now and again which can be tedious and even painful if you build PKI using it. The latter happened with a project I worked on where we’ve had to cycle our users keys for an application a few times now, I think jumping from 512 to 2048 and recently to 4096. This is even more tedious in a zero-knowledge system where the keys can only be unlocked with user authentication but deadlines for updating exist..

I’m not positive but I don’t think Elliptic Curves have the same issue, or key lengths have longer predicted life spans.

As far as I have been able to figure, 2048 bit RSA is good for the ages. It would take some fundamental breakthrough like quantum computing to break. No conceivable incremental improvement in current computing technology will come close to touching it.
> 2048 bit RSA is good for the ages

Estimates shows that state-level factorisation will be readily possible by 2030, and academic-size factorisation by five to ten years after that (this is just using classical computers).

No they are not. It is just some sort of internet legend going around right now. If I had to play the odds I would consider RSA more secure than curves simply because RSA has been solid for much longer than the current curves have existed.
There's a cherry on top there though: shorter RSA keys are easily breakable now, so most recommendation now focuses on extending from the defaults. It doesn't help that the practical default for SSH was 1024-bit until 2019-ish (OpenBSD folks: yes, OpenSSH did move to 2048-bit RSA way earlier, but OpenSSH builds on other OSes don't move that fast).
> What's the rationale for keeping RSA as a default these days?

Can't think of any reason except backwards compatibility and regulatory compliance.

I don't use anything except ED25519 in my own setup.

For me: great smartcard support. Smartcards with EC are still rare. I think the latest yubikeys can do it with OpenPGP but it takes some fiddling and I also use physical cards.

And really, RSA-2048 is more than sufficient to keep all but the most funded hackers out. And if those target me, they'll get in anyway.