8 ms·
The surprising persistence of RSA keys in SSH
- rubatuga 6y agoUnless there’s a good reason for not using RSA, this is a non-issue
- hyper_reality 6y agoCheck out the paper "Ron was wrong, Whit is right" for a survey of keys found on the web and the surprising number of RSA keys that have weaknesses.
- throw0101a 6y agoDiscussion of said paper (2012): * https://news.ycombinator.com/item?id=3591429 https://news.ycombinator.com/item?id=3591429
- phkahler 6y agoWhy do RSA keys have weaknesses? Wasn't the company found to be compromised and selling products that make weak keys or something like that?
- rcxdude 6y agocompletely different. RSA group != RSA the algorithm (though they were created by the same people initially).
- phkahler 6y agoI may have been thinking of this: https://www.google.com/amp/s/mobile.reuters.com/article/amp/idUSBRE9BJ1C220131220 https://www.google.com/amp/s/mobile.reuters.com/article/amp/...
- genr8 6y agoThere is a good reason, its just buried in complex crypto math and I won't be the one to explain it for you. If you are still using RSA, you should have upgraded to 4096 bit RSA by now. If not, you should be regenerating and changing your keys and not using one 5 or 10 year old 2048-bit RSA key because "2048 should be enough for anyone" and not thinking "I reused this key all over the place and im lazy and i'm sentimental and don't like change". People's key practices are just as bad as their password practices. His personal blog post was not meant to be a comprehensive lesson. But you can do what you want. If this is the first time you're hearing about RSA starting to be phased out, and the new Ed25519, look into it. Or click this if you're lazy. https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54 https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e... Also of note, is Ed25519 does not harden itself with additional "bits" in the normal RSA sense, it relies on "rounds" of KDF to apply more brute-force protection to the passphrase (you did set a passphrase on your key right?). I would suggest using the -a option with 1000 or more rounds. If you pick 50,000 rounds you might be waiting 5 minutes to log in though. Also of note, ECDSA (the other one) has had curve trust concerns due to NIST possibly being subverted by the NSA. You can read for days on this, but bottom line is we've all agreed to move on. https://security.stackexchange.com/a/227771 https://security.stackexchange.com/a/227771 / https://safecurves.cr.yp.to/ https://safecurves.cr.yp.to/
- LeoPanthera 6y agoCan you please provide a citation for 2048-bit RSA not being enough? That is counter to apparently reliable advice elsewhere.
- genr8 6y agoI didnt say it wasn't enough. I said you should upgrade to elliptic curve crypto, or if you have to stay on RSA, re-generate with 4096 because it's better. A 2048 bit RSA key only provides 112 bits of security - claimed to be suitable until the year 2030. RSA-2048 is still techncially ALLOWED by NIST, but that is the literal cutoff mark, below which is disallowed. The spec dates back to 2012 with "NIST Special Publication 800-57 Part1". This specification is up to Revision 5 now, the most recent of which is named "NIST Special Publication 800-57 Part 1 rev 5" published May 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... . There is no new news regarding the 2048 length since 2012. This estimate also does not factor in CLASSIFIED quantum cryptography thats hidden from the public. I personally don't trust them after the Snowden documents either. Plenty of sites are still using 2048 for compatibility and speed, but if you are re-generating your key now, its advised to upgrade to elliptic curve, or if you must stick on RSA, 3072 or 4096, because 2048 is the literal cutoff point. This document also describes the migration process. NIST SP 800-131A Rev. 2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/...
- theamk 6y agoNewer keys, especially ed25519, are very short. This makes working with them much easier. Copy-pasting them to remote machine is more reliable, examining authorized_keys us faster and so on.
- bawolff 6y agoThat may be true, but just because ed25519 might be better, doesn't mean RSA is a "problem"
- rakoo 6y agoIn the field of security, much more than in the rest of technology, age is an important factor of being a problem. SHA1 is merely starting to see attacks that can finally be demonstrated rather than theorized, that still take hundreds of CPU-year, 20 years after its inception. But we haven't waited all that time to retire SHA-1, because we know that eventually all schemes fail. Same holds for RSA.
- bawolff 6y agoAre there attacks on RSA with appropriate key sizes? We replaced SHA-1 because the attacks, even if just theoretical, were clearly on the horizon (and we replaced with sha-256 which is basically the same thing with a few tweaks and some parameters increased). RSA certainly has attacks, but they have been compensated with bigger key sizes. Is there any reason to suspect that 4096 bit RSA will be unsafe anytime soon, other than quantum computers? Disclaimer: Iana cryptographer
- nullc 6y ago> copy-pasting them to remote machine is more reliable, This has basically nothing to do with the underlying cryptosystem. Instead of explicitly configuring RSA keys, SSH could have been setup where you put their SHA256 hash in the authorized key file. (The pubkey itself would sent by the user at auth time and checked against its hash)
- beagle3 6y agoNeither the pgpcard (which I got from g10code while they were still selling them) nor my 100 or so Yubikeys purchased over the last 5 years support ed25519.
- p_l 6y agoAs far as I understand, none of the hw token vendors support ed25519, because none of the secure element vendors do. Your best bet is AFAIK ECDSA with NIST parameters.
- cjcampbell 6y agoYubikey is supporting ed25519 as of firmware 5.2.3 (https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-2-3/ https://www.yubico.com/blog/whats-new-in-yubikey-firmware-5-...)
- captn3m0 6y agoI’ll try to upgrade, thanks
- dmm 6y agoYou can't upgrade the Yubikeys. You have to buy a new one. https://support.yubico.com/support/solutions/articles/15000006434-upgrading-yubikey-firmware https://support.yubico.com/support/solutions/articles/150000...
- sterlind 6y agoUgh that's really frustrating. If it's for security, why can't they just blank the key like they do when the master key is used?
- cjcampbell 6y agoAhh, I should have made that more clear in my comment. Definitely frustrating, as those dang keys aren’t cheap!
- enzanki_ars 6y agoFor the longest time, to the best of my knowledge, instructions provided by GitHub and GitLab, probably the two most popular software with easy to access instructions on generating a SSH keys defaulted to displaying the RSA key generation instructions first instead of an Ed25519 key. The good news is that GitLab uses Ed25519 keys as the recommended default [0]. GitHub still recommends RSA keys by default [1]. [0]: https://docs.gitlab.com/ee/ssh/README.html#generating-a-new-ssh-key-pair https://docs.gitlab.com/ee/ssh/README.html#generating-a-new-... [1]: https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key https://help.github.com/en/github/authenticating-to-github/g...
- SomaticPirate 6y agoI’m still not sure why I should use Ed25519? Is it just cryptographically “tougher”?
- Enginerrrd 6y agoAs I understand it, it's computationally faster and the same key size confers much more security than RSA. That said, there are some elliptic curve skeptics out there that think the NSA has cooked certain curves or may have techniques we don't know about and that's why they've been pushing it so hard. The latter being less likely than the former. Don't use the NIST curves.
- numpad0 6y agoRSA getting weaker ECDSA suspected backdoored by NSA EdDSA/Ed25519 like ECDSA but community made RSA32768 might be okay but weird
- cryptonector 6y agoECDSA isn't thought to be backdoored so much as designed on purpose to be very difficult to get right / very easy to get catastrophically wrong.
- mercer 6y ago
- gok 6y agoIt's startling how much software "validates" SSH keys by seeing if it starts with "ssh-rsa"
- jonathanoliver 6y agoI'm still waiting for AWS EC2 to allow non-RSA keys. I've got other keys for everything else but an RSA for EC2.
- asguy 6y agoI was expecting this to be higher up. They're the only reason I still have an RSA key.
- usr1106 6y agoWhat service are you referring to? My EC2 instances running CoreOS Container Linux (moving to Fedora CoreOS as we speak...) have an ed25519 host key only and users can ssh in using their ed25519 key pair. Yeah, we don't create them using AWS web UI, but using terraform / ignition.
- jonathanoliver 6y agoSo when I use the EC2 web dashboard and try to add my SSH key, it gives me an error unless it's an RSA key. Obviously once I'm logged into a given sever over SSH, I can change my key to be whatever is supported by the underlying VM OS.
- cjcampbell 6y agoThis may not work for your requirements, but one approach worth considering is to create your instances without a key pair and then leverage Systems Manager to push your ed25519 keys to the system. This can be done with RunCommand, a manual Session Manager connection, or by storing your public keys in parameter store and pulling them in via a startup scrip in Instance Metadata. To take advantage of SessionManager or RunCommand, you do need to have the SSM agent installed along with an IAM role. This isn’t a fit for every set of requirements. The latter approach can be accomplished with a minimal IAM role and the AWS CLI. In the event your subnet doesn’t have NAT, you will need an SSM endpoint in your VPC.
- ryanlol 6y agoFWIW the .ssh/authorized_keys command= restriction for sftp doesn’t prevent arbitrary command execution if your system is configured with procfs. https://seclists.org/fulldisclosure/2014/Oct/35 https://seclists.org/fulldisclosure/2014/Oct/35
- theamk 6y ago> OpenSSH 6.7 contains a mitigation, > OpenSSH 6.7 was released on 2014-10-06. I am not sure why this matters? If you have not updated your system for 8 years, I am sure you have worse problems than restricted account privilege escalation.
- RcouF1uZ4gsC 6y agoI think a big reason for the persistence of RSA keys is that they are easier to understand than eliptical curve. Basically, every first year computer science student who has taken discrete math can write a (horribly broken, ineffecient) implementation of RSA encryption and decryption and have a pretty good intuitive understanding of what is going on. In fact, I did that just for fun as a first year CS student. With elliptical curves, I have read through the multiple websites and explanations and over several years and still feel I do not have an intuitive grasp of what is really going on.
- cordite 6y agoIn my second year, I had to do this on paper, showing every step. The prime sizes were about 10 digits as to keep things within a few sheets of paper. It seems my memory of it was traumatizing, one of the few assignments I had where I remember where I sat in the library computing this assignment on paper. Without electronic assistance.
- throwaway2048 6y agoelliptical curve crypto really is pretty simple when explained geometrically. https://arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ https://arstechnica.com/information-technology/2013/10/a-rel...
- mikedilger 6y agossh-keygen defaults to RSA
- LeoPanthera 6y agoI'm surprised that this isn't a bigger deal. Most people won't specify a type and use whatever the default is.
- AlphaSite 6y agoI think this varies by os.
- divbzero 6y agoAs the author mentions, defaults can play a significant role. In particular, it would probably help for ssh-keygen to default to ed25519.
- toyg 6y ago... and break tons of usages where the software does not support newer schemes? Switching defaults is always a complex trade-off.
- nullc 6y agoWhy would it be surprising? 4k and especially 8kbit RSA provide greater assumed security, and the cpu/communication performance of 4/8kbit RSA is perfectly adequate for SSH. They also provide greater compatibility. Why would I downgrade my cryptographic security to use a different cryptosystem with performance characteristics which aren't very relevant for interactive logins and get reduced compatibility at the same time? I'd be much more interested in an ed448 or a ed25519+SPHINCS+ hybrid for SSH authentication -- at least they wouldn't be unambiguously less secure than what I'm currently using per our best current understanding. Same deal for GPG/PGP: they added ed25519 which has less security than the keys most people were already using (4kbit RSA)... when the performance advantages are essentially irrelevant for the application. The non-performance related advantages seem small relative to to the compatibility and security posture.