Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH Keygen – RSA, DSA, Ecdsa, EdDSA

gravitational.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#31

Post by Arnavion »

hal9000-tng wrote: post #30

This isn't that complicated. The answer is, simply: ED25519 if you're using modern services that support it. or RSA (4096 or at least 2048 bits) for services that cannot handle ED25519 (including AWS -- yes, still, even in 2020.) So you should probably generate both to cover most possible scenarios: ssh -t ed25519 # for most purposes (not AWS) ssh -t rsa -b 4096 # for when you're not using something like Userify

>services that cannot handle ED25519 (including AWS -- yes, still, even in 2020.)

I assume this is about provisioning VMs, and even then only about setting the initial ssh key at provisioning time? I can't imagine why AWS would care what kind of ssh keys a VM uses after it's been provisioned.

If so, you can just create a temporary RSA key used to provision the VM, immediately replace it with an ed25519 one and throw away the RSA one. That's what I do with Azure VMs since Azure has the same RSA-only requirement silliness for what amounts to writing a blob of user-provided text to a file.

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#32

Post by pvg »

brobinson wrote: post #24
pvg wrote: post #7

Earlier quoted context omitted.

It's not about the answer itself but the structure of the piece. For that kind of info, this is the better template: https://codahale.com/how-to-safely-store-a-password/

This is outdated in terms of recommending bcrypt blindly. Bcrypt has some flaws (leading null bytes, being only "cpu hard") that are addressed by newer hashing functions. Argon2 in independent mode or hybrid mode seems to be the most common recommendation among security luminaries today.

https://news.ycombinator.com/item?id=24286955

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#33

Post by a1369209993 »

rurban wrote: post #10
jandrese wrote: post #4

Earlier quoted context omitted.

The answer is Ed25519, as most people probably expected.

Or RSA 4096. Ed25519 certainly looks the best given the fact that all the spooks (NIST, cryptlib, Crypto++ ...) lobby against it, and didn't implement it. Looks like that is the one they want nobody to use, even if it's the simplest. However, any elliptic curve in general can be backdoored, the FSF recommends RSA 4k only. Even if RSA side channel attacks are known.

Fuck RSA.[0][1]

> The fact that RSA is still in widespread use today indicates both a failure on the part of cryptographers for not adequately articulating the [many] risks inherent in RSA, and also on the part of developers for overestimating their ability to deploy it successfully.

0: PoC||GTFO 20 (https://www.alchemistowl.org/pocorgtfo/pocorgtfo20.pdf) 20:09 (p 68)

1: Why yes, that is a direct quote.

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#34

Post by dependenttypes »

aborsy wrote: post #26
dependenttypes wrote: post #20

Earlier quoted context omitted.

As far as I know elliptic curves at the same size as RSA are stronger both in a quantum and post-quantum setting.

True, in fact an elliptic key with 4096 bits would be way overkill. But there is also the issue of support. Ed25519 and RSA3072 offer around 128 bits of entropy, which is kind of on margin even classically. RSA 4096 offers more protection against brute force, around 144 bits if I recall correctly. Of course, RSA is vulnerable to side channel attacks (though these nay not be in the threat model of many people). You co…

> which is kind of on margin even classically

Is it though? It requires around 2^128 operations to be broken. It does not seem very marginal to me.

It is not like AES where you have to deal with batch-attacks or cryptographic hash functions where collisions for a n-length output require only sqrt(2^n) attempts.

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#35

Post by a1369209993 »

throw0101a wrote: post #6

The conclusion has the line: > […] while EdDSA performs much faster and provides the same level of security with significantly smaller keys. For non-embedded systems, how important is the speed and/or size consideration? Keys are (IIRC) only used on initial contact, and the bulk of traffic operations will use symmetrical algorithms, so it it that big of a deal? Perhaps throwing around a comparatively short "id_ed2551…

> For non-embedded systems, how important is the speed and/or size consideration?

Let's put it this way, ed25519 keys take up this much space:

  sTSv4xsmaTqwhi3Qzj16w+zlRBxBvn+F3IVmxUwNkTg=
While RSA 4096 keys take up this much space:

  vUvYsQlH1yvH3KE+uJbbb8TwgvVruQpFaLzoUThFPrGKVJ+qgJqmNaMclqGnTfFb
  a6y9n4h4c5rWRX1jmzr/w72StPYbxdmxq/aTZWPWEaokQHupbk24idxxJDJXhFOm
  nJYLKe3R+14ps4n396r5sF9iyC5azqUPXKUX5k94O1wSeUrqSkW19Qu5jVYhAbBq
  aI1oUlf6Aij2pcrCIEORGqhFClLhN1H4turNPJlsw7wTeq1YVvOWYM6PKSGrlt8I
  mEgXoNnlsHnFDTZpu7ndyT2+fGfVHlVqRqEiKL53PzVUqDZYIOiclH92Y6yWOze+
  WteZjvrk1S2jdcuyEpn9mBCoz2o1koiS4F2Y8wsRtD4YZC1RSIcaul/vWp/tETqn
  zCcVysEdEbVkuzBcEc2g2P6pky4QT1o8IR/g33TRFOjkrNGekf/8ZNLhAPuoclxa
  K0LKpzV09MT5YIunkZgH+ZwDhKOcCaXweVYHoiO/BO/gP9DS93LlbsvVcrm02CYh
  V9Cl98iUuBgPLT/xMP7C4ZxwR2Dtc0kLP8fJqmy3HaeNqyEk1eEF1hGPsizWjQo8
  rABXBxNuoKD2m0SGmy4BDtQKLibushIlhoNMrkmvdNahOaEUPAgCLRYK1CN7082p
  CaYk76FZ32ZBSQ4yiFrLrewBhYdJTxkUdLgUFGo2Ie8=
In other words ed25519 keys are something you can reasonably expect people to copy-paste and otherwise work with as if they were URLs or content-addresses like md5 file hashs. RSA keys... aren't. You can work around this with keyservers and the like, but that adds more moving parts and more opprotunities for things to break for no reason.

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#36

Post by tialaramex »

m-p-3 wrote: post #28
gnufx wrote: post #13

Earlier quoted context omitted.

There's support in hardware tokens to consider too.

I'd use my Yubikey 4 more if it did.

More if it did what? If you're avoiding the Yubikey's onboard ECDSA because you're worried ECDSA is weaker than EdDSA that's definitely crazy. The main thing the Yubikey is doing for you is protecting that private key from just straight up getting stolen, whereupon it could be some future quantum-proof magic and you're still screwed because now the adversary has it.

The OpenSSH FIDO implementation offers ECDSA because it makes sense to use ECDSA on older authenticators that don't offer anything better rather than go without. If there were any stand alone authenticators (as opposed to hybrid software like Microsoft Hello) that only offered RSA then I suspect OpenSSH would sigh and allow that too. For all that Safer Curves makes out it's the end of the world, bad guys really do steal SSH private key files and they don't actually perform crazy timing attacks on ECDSA because it's very hard.

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#37

Post by ShorsHammer »

benlivengood wrote: post #14

The only downside to Ed25519 is that it will fall to quantum computing before RSA 4096.

OpenSSH has a post-quantum hybrid algo using SNTRUPrime and ed25519.

> * ssh(1), sshd(8): Add experimental quantum-computing resistant key exchange method, based on a combination of Streamlined NTRU Prime 4591^761 and X25519.

https://www.openssh.com/txt/release-8.0

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#39

Post by lervag »

hal9000-tng wrote: post #30

This isn't that complicated. The answer is, simply: ED25519 if you're using modern services that support it. or RSA (4096 or at least 2048 bits) for services that cannot handle ED25519 (including AWS -- yes, still, even in 2020.) So you should probably generate both to cover most possible scenarios: ssh -t ed25519 # for most purposes (not AWS) ssh -t rsa -b 4096 # for when you're not using something like Userify

It should be "ssh-keygen", not "ssh".

    ssh-keygen -t ed25519
    ssh-keygen -t rsa -b 4096

Re: SSH Keygen – RSA, DSA, Ecdsa, EdDSA

#40

Post by aborsy »

dependenttypes wrote: post #34
aborsy wrote: post #26

Earlier quoted context omitted.

True, in fact an elliptic key with 4096 bits would be way overkill. But there is also the issue of support. Ed25519 and RSA3072 offer around 128 bits of entropy, which is kind of on margin even classically. RSA 4096 offers more protection against brute force, around 144 bits if I recall correctly. Of course, RSA is vulnerable to side channel attacks (though these nay not be in the threat model of many people). You co…

> which is kind of on margin even classically Is it though? It requires around 2^128 operations to be broken. It does not seem very marginal to me. It is not like AES where you have to deal with batch-attacks or cryptographic hash functions where collisions for a n-length output require only sqrt(2^n) attempts.

That’s not how it works!

That 128 bits is theoretical upper bound, not necessarily an achievable security rate. That’s the point of margin.

Post reply on HN