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

21–30 of 45 posts

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

#21

Post by tialaramex »

Three of these four algorithms are only for signing and although you can use RSA to do either, in SecSH (and thus modern SSH) it is only used for signing.

So it's a red flag when articles like this start jabbering about using these signature algorithms for encryption:

> This is what is meant by asymmetric encryption. [Figure 2] If Bob encrypts a message with Alice’s public key, only Alice’s private key can decrypt the message. This principle is what allows the SSH protocol to authenticate identity. If Alice (client) can decrypt Bob’s (server) message, then it proves Alice is in possession of the paired private key. This is, in theory, how SSH keys authentication should work.

No. This isn't how SSH works, and it's confusing to me that people prefer to imagine how it could work rather than just read the specification. RFC4252 explains exactly how public key authentication is performed. Alice signs a standard message bound to this SSH session using her private key, and Bob can verify that this signature is correct using her public key.

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

#22

Post by kbirkeland »

rakoo wrote: post #11

SSH is basically everywhere, and the key generation topic keeps coming regularly. At this point it probably deserves an entry in the Cryptographic Right Answers ( https://latacora.micro.blog/2018/04/03/cryptographic-right-a... ) to end debates once and for all

While not explicitly pointed toward SSH, the "Asymmetric signatures" section covers this. Their recommendation is to use Ed25519 and avoid all other options mentioned in the article.

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

#23

Post by boxfire »

rakoo wrote: post #11

SSH is basically everywhere, and the key generation topic keeps coming regularly. At this point it probably deserves an entry in the Cryptographic Right Answers ( https://latacora.micro.blog/2018/04/03/cryptographic-right-a... ) to end debates once and for all

Such a mixed signal from that blog. At first it explained broken security, and then recommended I run only binaries passed down from God. Luckily I'm a believer in rational security and wouldn't run this program if I actually cared about security.

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

#24

Post by brobinson »

pvg wrote: post #7
jandrese wrote: post #4

Earlier quoted context omitted.

The answer is Ed25519, as most people probably expected.

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.

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

#25

Post by i-am-curious »

tialaramex wrote: post #21

Three of these four algorithms are only for signing and although you can use RSA to do either, in SecSH (and thus modern SSH) it is only used for signing. So it's a red flag when articles like this start jabbering about using these signature algorithms for encryption: > This is what is meant by asymmetric encryption. [Figure 2] If Bob encrypts a message with Alice’s public key, only Alice’s private key can decrypt th…

> This principle is what allows the SSH protocol to authenticate identity.

This part is also confusing. I feel like it is important to clarify that identity is not "established" using cryptography, rather verified. When Bob claims to be the Bob, you don't know and can't know just from this claim if Bob is indeed the Bob. To verify that this Bob is indeed the Bob, you have him certify from someone else that you trust that he is indeed the Bob (or you just certify it yourself when your computer asks you to trust a new fingerprint).

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

#26

Post by aborsy »

dependenttypes wrote: post #20
benlivengood wrote: post #14

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

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 could use ed448 with 224 bits of security with still shorter keys than common RSA variants. But then it’s not supported in most places.

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

#28

Post by m-p-3 »

gnufx wrote: post #13
benarent wrote: post #5

If you setup SSH keys a while ago, you might want to run the below command to discover the type / key strength. If you're reading HackerNews comments, this might be good time to run an audit. Also; before going all in on Ed25519, native support from some cloud providers is limited. $ for key in ~/.ssh/id_*; do ssh-keygen -l -f "${key}"; done | uniq

There's support in hardware tokens to consider too.

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

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

#29

Post by doctoboggan »

benarent wrote: post #5

If you setup SSH keys a while ago, you might want to run the below command to discover the type / key strength. If you're reading HackerNews comments, this might be good time to run an audit. Also; before going all in on Ed25519, native support from some cloud providers is limited. $ for key in ~/.ssh/id_*; do ssh-keygen -l -f "${key}"; done | uniq

is 2048/SHA256 long enough?

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

#30

Post by hal9000-tng »

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
Post reply on HN