4 ms·

If you're like me and have just been using RSA because of inertia, here's a discussion of why you might switch to ed25519 as an alternative: https://www.reddit

If you're like me and have just been using RSA because of inertia, here's a discussion of why you might switch to ed25519 as an alternative: https://www.reddit.com/r/sysadmin/comments/4gktbr/ssh_ed25519_keys_vs_rsa_benefits_and_drawbacks/ https://www.reddit.com/r/sysadmin/comments/4gktbr/ssh_ed2551... I particularly enjoyed this answer: > ed25519 is more secure in practice. One of the biggest reasons to go with ed25519 is that it's immune to a lot of common side channels. While ed25519 is slightly less complex to crack in theory, in practice both of them are long enough that you're never going to be able to crack it, you need a flaw to exploit in the implementation or a substantial leap forward in cryptanalysis. ed25519 is more secure in practice because most instances of a break in any modern cryptosystem is a flaw in the implementation, ed25519 lowers the attack surface here.

thomasahle 5y ago
I feel like the Dual_EC_DRBG backdoor has given Elliptic Curve Crypto a bad reputation lasting for decades. I guess it's unfair to the technology as a whole, but somehow RSA just feels safe and battle tested.
- chasil 5y ago
  The tinyssh server only uses DJB cipher suites; the curve25519-sha256@libssh.org implementation has been in place for quite some time without any major issues. https://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/ https://www.libssh.org/2013/11/03/openssh-introduces-curve25... "This algorithm does not rely on NIST-based curves and gives us more security confidence against a possible backdoor in nistp-256 curve. Today is a big day for us because OpenSSH team approved my patch and made curve25519-sha256@libssh.org the default key exchange!" Also, the original RSA keys used in SSH have a sha-1 problem, and have been deprecated. https://www.zdnet.com/article/openssh-to-deprecate-sha-1-logins-due-to-security-risk/ https://www.zdnet.com/article/openssh-to-deprecate-sha-1-log... https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K [1] For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible. Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol.
  - hannob 5y ago
    The concerns about the nist curves and the dual ec issue are two completely separate things. Furthermore: > Also, the original RSA keys used in SSH have a sha-1 problem, and have been deprecated. This is wrong. What's correct is that openssh plans to deprecate sha1 signatures, but you can still use your RSA keys with sha2-based signatures.
- gurrone 5y ago
  Ironically I lately had a payment service provider handing me newly generated ecdsa ssh keys where ed25519 should be supported to the best of my knowledge. And fluxcd moved from rsa to ecdsa by https://github.com/fluxcd/flux2/releases/tag/v0.21.0 https://github.com/fluxcd/flux2/releases/tag/v0.21.0. Kinda strange people are moving on to EC cipher - which is good, but to the cipher which has the NIST/NSA smell.
  - chasil 5y ago
    I have upgraded all of my ECDSA host keys to the 521 curve, which has some praise from DJB, unlike the 256 and 384 curves (ssh-keygen -b #: "For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits"). http://blog.cr.yp.to/20140323-ecdsa.html http://blog.cr.yp.to/20140323-ecdsa.html "To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 - 1; but the sheer size of this prime makes it much slower than NIST P-256."
hannob 5y ago
I'm not sure I agree with that. One thing to keep in mind is that SSH uses RSA only for signatures. That already kills off most attacks on RSA, as encryption has always been weaker than signatures. Not using a small exponent key kills the most significant attack on signatures. Regarding sidechannels, the biggest issue I can think of is that ideally you should have constant time modular arithmetic, but you need that for ed25519 as well. Not necessarily advocating for RSA (ed25519 is fine I guess), but I feel the "RSA is bad" talking point has been overused.
- mananaysiempre 5y ago
  From when I last looked, my impression was that the specific modular arithmetic you need for ed25519 is basically standard long arithmetic with a constant number of digits + a single CMOV, which is different from essentially arbitrary moduli that (reasonably compatible) RSA needs.
apatheticonion 5y ago
ed25519 makes me feel like an idiot because I can never remember it. When I create new ssh keys I always forget: 1) (minor) The command to use a different encryption method to the default one 2) (major) how to remember more than the first two characters of ed25519 When I feel serious about not using RSA, I literally google "ssh ed" and pray it will autofill the rest of it. If I am not there within 15 seconds of opening my browser I am rolling with RSA256.
- ThePowerOfFuet 5y ago
  RSA2048, you mean? ;)
  - apatheticonion 5y ago
    Haha! Oh wow, case and point - I am hopeless at anything that isn't the default
    - ThePowerOfFuet 5y ago
      This is what makes Wireguard so powerful: there is only one setting.

thomasahle 5y ago

I feel like the Dual_EC_DRBG backdoor has given Elliptic Curve Crypto a bad reputation lasting for decades. I guess it's unfair to the technology as a whole, but somehow RSA just feels safe and battle tested.

chasil 5y ago
The tinyssh server only uses DJB cipher suites; the curve25519-sha256@libssh.org implementation has been in place for quite some time without any major issues. https://www.libssh.org/2013/11/03/openssh-introduces-curve25519-sha256libssh-org-key-exchange/ https://www.libssh.org/2013/11/03/openssh-introduces-curve25... "This algorithm does not rely on NIST-based curves and gives us more security confidence against a possible backdoor in nistp-256 curve. Today is a big day for us because OpenSSH team approved my patch and made curve25519-sha256@libssh.org the default key exchange!" Also, the original RSA keys used in SSH have a sha-1 problem, and have been deprecated. https://www.zdnet.com/article/openssh-to-deprecate-sha-1-logins-due-to-security-risk/ https://www.zdnet.com/article/openssh-to-deprecate-sha-1-log... https://www.openssh.com/releasenotes.html https://www.openssh.com/releasenotes.html This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K [1] For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible. Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol.
- hannob 5y ago
  The concerns about the nist curves and the dual ec issue are two completely separate things. Furthermore: > Also, the original RSA keys used in SSH have a sha-1 problem, and have been deprecated. This is wrong. What's correct is that openssh plans to deprecate sha1 signatures, but you can still use your RSA keys with sha2-based signatures.
gurrone 5y ago
Ironically I lately had a payment service provider handing me newly generated ecdsa ssh keys where ed25519 should be supported to the best of my knowledge. And fluxcd moved from rsa to ecdsa by https://github.com/fluxcd/flux2/releases/tag/v0.21.0 https://github.com/fluxcd/flux2/releases/tag/v0.21.0. Kinda strange people are moving on to EC cipher - which is good, but to the cipher which has the NIST/NSA smell.
- chasil 5y ago
  I have upgraded all of my ECDSA host keys to the 521 curve, which has some praise from DJB, unlike the 256 and 384 curves (ssh-keygen -b #: "For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits"). http://blog.cr.yp.to/20140323-ecdsa.html http://blog.cr.yp.to/20140323-ecdsa.html "To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 - 1; but the sheer size of this prime makes it much slower than NIST P-256."

hannob 5y ago

I'm not sure I agree with that. One thing to keep in mind is that SSH uses RSA only for signatures. That already kills off most attacks on RSA, as encryption has always been weaker than signatures. Not using a small exponent key kills the most significant attack on signatures. Regarding sidechannels, the biggest issue I can think of is that ideally you should have constant time modular arithmetic, but you need that for ed25519 as well. Not necessarily advocating for RSA (ed25519 is fine I guess), but I feel the "RSA is bad" talking point has been overused.

mananaysiempre 5y ago
From when I last looked, my impression was that the specific modular arithmetic you need for ed25519 is basically standard long arithmetic with a constant number of digits + a single CMOV, which is different from essentially arbitrary moduli that (reasonably compatible) RSA needs.

apatheticonion 5y ago

ed25519 makes me feel like an idiot because I can never remember it. When I create new ssh keys I always forget: 1) (minor) The command to use a different encryption method to the default one 2) (major) how to remember more than the first two characters of ed25519 When I feel serious about not using RSA, I literally google "ssh ed" and pray it will autofill the rest of it. If I am not there within 15 seconds of opening my browser I am rolling with RSA256.

ThePowerOfFuet 5y ago
RSA2048, you mean? ;)
- apatheticonion 5y ago
  Haha! Oh wow, case and point - I am hopeless at anything that isn't the default
  - ThePowerOfFuet 5y ago
    This is what makes Wireguard so powerful: there is only one setting.