4 ms·

No RSA support really stands out. No doubt many reading this have RSA identity keys on disk right now in ~/.ssh. It's been the default for so long.

turminal 5y ago
Being tiny always means giving up some features. Supporting RSA really doesn't go along well with being tiny & straightforward.
- asveikau 5y ago
  It's their own project and their decision to make. That said, have you read an RSA implementation? It's not a lot of code.
  - turminal 5y ago
    It's not a lot of code but it's significantly less straightforward than the primitives tinyssh offers.
rectang 5y ago
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.
nine_k 5y ago
Existing keys matter little. I always generate a new key for a new host anyway. Makes revocation much easier.
- asveikau 5y ago
  For a new server, sure. I meant your personal identity key in ~/.ssh/id_*. The one that you might have on a bunch of servers, or give to github, or whatever. It's a good practice to periodically regenerate those, but I don't think it happens quite as often.
  - nine_k 5y ago
    > The one that you might have on a bunch of servers, or give to github, or whatever Exactly what I avoid. Each of them gets their own separate key. Never the same key to a bunch of machines (except maybe transient VMs). But I agree, if a server changes its SSH implementation to one that does not support your existing key, it's a hassle, to say the least. In reasonable circumstances this does not happen without a plenty of warning well ahead of time, to allow you to regenerate your key in a new format.
Beltiras 5y ago
Anyone fluent enough to read these type of posts and threads are very comfortable to moving to elliptic curve.

turminal 5y ago

Being tiny always means giving up some features. Supporting RSA really doesn't go along well with being tiny & straightforward.

asveikau 5y ago
It's their own project and their decision to make. That said, have you read an RSA implementation? It's not a lot of code.
- turminal 5y ago
  It's not a lot of code but it's significantly less straightforward than the primitives tinyssh offers.

rectang 5y ago

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.

nine_k 5y ago

Existing keys matter little. I always generate a new key for a new host anyway. Makes revocation much easier.

asveikau 5y ago
For a new server, sure. I meant your personal identity key in ~/.ssh/id_*. The one that you might have on a bunch of servers, or give to github, or whatever. It's a good practice to periodically regenerate those, but I don't think it happens quite as often.
- nine_k 5y ago
  > The one that you might have on a bunch of servers, or give to github, or whatever Exactly what I avoid. Each of them gets their own separate key. Never the same key to a bunch of machines (except maybe transient VMs). But I agree, if a server changes its SSH implementation to one that does not support your existing key, it's a hassle, to say the least. In reasonable circumstances this does not happen without a plenty of warning well ahead of time, to allow you to regenerate your key in a new format.

Beltiras 5y ago

Anyone fluent enough to read these type of posts and threads are very comfortable to moving to elliptic curve.