25 ms·

Upgrade your SSH keys

• qzervaas 10y ago
  For those who have just updated to macOS Sierra, the default SSH client configuration is to not allow ssh-dss keys any longer. Follow these instructions to update your keys.
• matt_wulfeck 10y ago
  I disagree with the author. Before you go upgrading into ed25519, beware that the NSA/NIST is moving away from elliptical curve cryptography because it's very vulnerable to cracking with quantum attacks[0]. "So let me spell this out: despite the fact that quantum computers seem to be a long ways off and reasonable quantum-resistant replacement algorithms are nowhere to be seen, NSA decided to make this announcement publicly and not quietly behind the scenes. Weirder still, if you haven’t yet upgraded to Suite B, you are now being urged not to. In practice, that means some firms will stay with algorithms like RSA rather than transitioning to ECC at all. And RSA is also vulnerable to quantum attacks." Stick with the battle tested RSA keys, which are susceptible but not as much as ECC crypto. 4097 or even better 8192-bit lengths. There's no perceptible user benefits to using ed25519 and it's not even supported everywhere. Also you won't have to rotate all of your keys when workable quantum computers start crackin' everything. [0] https://blog.cryptographyengineering.com/2015/10/22/a-riddle-wrapped-in-curve/ https://blog.cryptographyengineering.com/2015/10/22/a-riddle...
  • tptacek 10y ago
    Both RSA and Elliptic Curve will fall to practical quantum computing, so the idea that you should use (weaker, slower) RSA today instead of curves because of QC is... dubious. If you see quantum computing as a practical threat (because: you're encrypting and storing static data that needs to resist cryptanalysis for 20-50 years), you need to use a post-quantum cryptosystem. Unfortunately: nobody knows which pq systems will truly hold up to practical quantum computing, and it's possible --- even likely --- that implementations of pq schemes have dumb errors that nobody has thought to check for yet. That's why Google's first foray into deploying pq crypto feeds both a curve computation and a Ring-LWE PQ computation into its KDF, so that unknown bugs in the RLWE exchange can't destroy the security of TLS. That's how you would seriously account for quantum computing in SSH. The recommendations in this post are solid.
    • hannob 10y ago
      There is one argument to be made in favor of large key RSA when it comes to quantum computers: ECC may fall a bit earlier. There can be a situation where it's feasible to produce a quantum computer large enough to tackle a 255 bit ECC key, but not a 4096 RSA key. I have heard from (a few) cryptographers that this is a reason to stick with "old school" DH/RSA crypto. I discussed this with various people involved in the postquantum debate and the general feedback I got was that this is likely not a big issue, because once quantum computers can be scaled it'll probably not be that hard to scale them up to RSA-breaking size. I think DJB once said something like "this will buy you a year" to me.
  • paulddraper 10y ago
    "battle tested" and "resistant to quantum computing" are complete opposites
    • dasil003 10y ago
      Orthogonal?
      • paulddraper 10y ago
        Yeah.
      • JshWright 10y ago
        Well, at the moment, they are "opposite" as well. No battle tested crypto schemes are post-quantum safe, and no post-quantum crypto schemes are battle tested.
  • nzp 10y ago
    IAD recommends not upgrading to ECC in case this would incur significant costs, only to have to upgrade again once they settle on quantum resistant algos. So not because of crypto reasons, not because ECC is more vulnerable to quantum attacks relative to RSA, but because of practical operational and economic reasons. They think they will have quantum algorithms soon enough so that RSA >=3072 is OK in the meantime. At least that's my understanding of what they're saying here: https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite....
  • ericfrederich 10y ago
    Are we not questioning the NSA's motives here given recent events? "Don't use elliptical curve crypto because it's vulnerable to quantum attacks... keep using the stuff that is vulnerable to our in-house attacks"
• pg_is_a_butt 10y ago
  LOL! nice try obama. more security with a private key that is only 68 characters! and they claim that is a benefit because of all the copy and pasting you do... you know... because it's so much harder to copy and paste twice as many characters. select all, ctrl-c... OH NO! and yet it's brute force safe! you know... because making the keyspace smaller by orders of magnitude makes brute force... harder? elliptic curves! you mean like the last try the NSA did to weaken the privacy of everyone? let me guess... the arbitrary coefficient is 777 again? JACKPOT! WE OWN ALL THE IDIOTS. you are all idiots.
• based2 10y ago
  https://www.reddit.com/r/netsec/comments/543ncp/upgrade_your_ssh_keys_how_to_get_rid_of_dsa_and/ https://www.reddit.com/r/netsec/comments/543ncp/upgrade_your...
  • technion 10y ago
    I always find it interesting to see the disparity between comments here, and in /r/netsec on matters like this. Here: Generally positive. Netsec: Most upvoted comments being complaints and assertions that it's bad advice. And for some reason, upvoted comments about NSA involvement in curves (which is exactly what 25519 is not).
    • dredmorbius 10y ago
      Constructing an open-access forum such that the most highly rated comments actually have high levels of information and relevance is difficult at best. Probably impossible without some specific test / proof of competence in the area.
    • Klathmon 10y ago
      I've started moving away from reddit for any kind of actual discussion about technical topics. It's just so... Toxic. I don't know if it's just my point of view changing, or if it's gotten worse over the last few years, but when I see a thread there later, the top comments are always negative, dismissive, and so full of bullshit. Just look at the recent Lenovo issue, HN had some good discussion on on what could be the actual causes and how to fix some of these problems (and why MS isn't entirely off the hook there), but reddit was just full of "Microsoft loves Linux!" Jokes and whichunting with very little to go on.
  • tedunangst 10y ago
    Was half expecting to see somebody say "rainbow table", but the comment in question is even better than I could have imagined.
    • technion 10y ago
• jlgaddis 10y ago
  If you have any RHEL machines, you might wanna keep an RSA (or ECDSA) key around. RHEL doesn't support Ed25519. I haven't checked, but I presume this also goes for CentOS, Scientific Linux, and other derivatives.
  • loeg 10y ago
    The article claims that RHEL7 supports Ed25519. Maybe RHEL6 and older do not.
• deleted 10y ago
  [deleted]
• LeoPanthera 10y ago
  Can someone explain to me why RSA 2048 is "recommended to change"? It's still the default for gpg keys and as far as I know is widely thought to be secure for at least few hundred years!
  • technion 10y ago
    Without commenting at all on the practicalities of attacking it, it's reasonable to expect a higher level out of security from GPG than a standard TLS connection. Your web server needs to key and manage many connections/sec, and any delays feed back into my web developers further arguing against the use of TLS. You can generally expect no one will be trying to break your current TLS sessions ten years from now. If that doesn't apply to your situation, you probably have bigger problems, such as the broken CA model. Both of these scenarios may be different with GPG.
  • fjarlq 10y ago
    It could have to do with the NSA's August 2015 plan for transitioning to quantum-resistant algorithms. In their new Commercial National Security Algorithm (CNSA) Suite, they advise a minimum 3072-bit RSA modulus: https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.... (Doh... I don't know why I'm getting an invalid certificate authority error when trying to access that site, but Qualys SSL Labs confirms it's a real error. Yikes.)
    • mastazi 10y ago
      I did not read it due to the certificate problem. Could someone post an abstract here?
      • fjarlq 10y ago
        Here's a copy of their CNSA FAQ: https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computin...
    • mastazi 10y ago
• loeg 10y ago
  RSA 2048 is still the openssh default, i.e., best current advice from the openssh authors. The fact that this article's author labels that as "yellow" is a red flag.
  • necessity 10y ago
    Yeah, I don't get it either.
  • mastazi 10y ago
    I agree. It would be nice if the line: > RSA 2048: yellow recommended to change was followed by at least some link that explains why is it unsafe. Could anyone elaborate further? UPDATE: there is now a link up in this thread, from the user fjarlq, which points to an NSA recommendation from 2015. The recommendation seems to be related to the need of having a "quantum computing resistant" key. But with quantum computing still in its infancy, how do we know which types of keys would be adequate?
    • riffraff 10y ago
      I think we don't know which one will be adequate but we do know that RSA won't be, hence the recommendation.
    • lmm 10y ago
      Many theoretical aspects of quantum computing are well-understood, just as a lot of early work on computational complexity etc. predates the existence of (nonhuman) computers.
  • geerlingguy 10y ago
    The same arguments were being made in some Reddit threads on the same post; I don't see any reason or new information to point towards RSA 2048 being a questionable or unreasonable choice. If quantum computing becomes more accessible, there will be a quantum shift (forgive the pun) in how we secure our connections.
    • 10y ago
• jamiesonbecker 10y ago
  In Userify (ssh key manager that only distributes sudo roles and public keys -- you keep your private keys[1]) we're going to be disallowing DSS keys soon. I like this post - it's good advice overall. Keys are easy to handle and in some ways more secure than certificate management (which relies on extra unnecessary infrastructure). 1. https://userify.com https://userify.com
  • manyxcxi 10y ago
    Off topic, but I want to thank you guys again for your service. You guys make it so freaking easy to manage access to our various servers and VMs- I can't even remember how we used to deal with it.
    • pg_is_a_butt 10y ago
      you sound like a great customer! i bet you won't forget to cancel your subscription payments either. or is this a shill thing? sorry, i'll leave you two at it. say something else. you're all idiots.
    • jamiesonbecker 10y ago
      Thank you! I don't know who you are (feel free to email me @ userify.com) but we really really really love to hear stuff like that. We are launching in AWS Mktplace soon too btw!
• stock_toaster 10y ago
  github doesn't support ed25519 keys does it?
  • cm3 10y ago
    Both GitLab and GitHub do in their SSH implementation.
  • auxym 10y ago
    Last I checked bitbucket.org didn't
    • sandGorgon 10y ago
      I just tried. Bitbucket was working ok. What issues are you facing? I'm on a fedora 24 laptop.
  • y-satellite 10y ago
    Just tried it out; works fine.
    • stock_toaster 10y ago
      Oh really? Last time I tried it I think it didn't. I assume they added support for it in the meantime... Great!
• katzgrau 10y ago
  Security is not my specialty, but I obviously wade in this field, being a developer. Having read this article I will say this to OP and the author: Thank you, I am sufficiently paranoid enough to change my keys now.
• Achshar 10y ago
  Noob question here, why move just one step ahead. Why not 8192 or hell 16,384? I can see it can lead to higher CPU consumption on often used keys but for keys that are not accessed more than a couple of times a day, why is it such a bad idea to overdo it?
  • loeg 10y ago
    4096+ is noticeably slower.
  • karmajunkie 10y ago
    someone correct me if i'm wrong, but I believe its not just used once a day. Its used for every packet you send while connected.
    • warkdarrior 10y ago
      Those keys are used at the beginning of each connection, primarily to authenticate and negotiate a session key. The session key is then used for every packet.
    • cscheid 10y ago
      I'm pretty sure you're wrong. These asymmetric crypto keys, with which it takes a long time to encode/decode, are used only at handshake to securely negotiate a per-session key that's used in symmetric crypto, for which encoding and decoding is extremely fast.
      • karmajunkie 10y ago
        I am indeed mistaken, thanks!
    • brandmeyer 10y ago
      The ssh protocol specs are actually quite readable. No, the slow asymmetric key is only used once to derive a fast symmetric key for the session. If you a set up a control master, then repeated logins to the same server (within some narrow window) will all multiplex over the same channel, too.
• tw04 10y ago
  This is my standard on new server setup (which is admittedly overkill but I'd rather have it slightly slower and safer): http://www.catb.org/esr/sshexport/ http://www.catb.org/esr/sshexport/ https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... SERVER SIDE: sources.list (if you're on an older version of debian) deb http://http.debian.net/debian http://http.debian.net/debian wheezy-backports main apt-get -t wheezy-backports install --reinstall ssh ==== cd /etc/ssh rm ssh_host_key ssh-keygen -t ed25519 -f ssh_host_ed25519_key -a 256 < /dev/null ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null (do not password protect server side keys) ==== /etc/ssh/sshd_config Protocol 2 HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com ==== CLIENT SIDE: /etc/ssh/ssh_config Host * KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com ==== ssh-keygen -t ed25519 -a 256 -f yourkey.key -C whateveryouwant
  • johnhenry 10y ago
    Do you have a link to a gist and/or your other work?
    • tw04 10y ago
      To be clear, the links at the top aren't mine (sorry if it seemed that way). Just sources I've used to create what I've got.
  • sandGorgon 10y ago
    why do you need to do client-side ? The server side will enforce the algorithms that are allowed.
• brandmeyer 10y ago
  If you have servers too old to work with the latest keys, you can easily modify your ~/.ssh/config to automatically use a per-machine private key file: Host foo.example.com Keyfile ~/.ssh/my_obsolete_private_keyfile
  • fphilipe 10y ago
    That you should be doing anyways, shouldn't you?
    • Godel_unicode 10y ago
      You certainly can, it's almost certainly unnecessary though. SSH keys are not like passwords, compromise of a server with your pubkey in no way effects the security of your private key. Many people will post pubkeys online so they're easy to add to new servers.
      • Nullabillity 10y ago
        Adding to this: GitHub publishes the public SSH keys of all of their users, for example: https://github.com/teozkr.keys https://github.com/teozkr.keys
      • x1798DE 10y ago
        I use a different keypair for every service, and for each device connecting to the service because keys are cheap and easy to manage. One advantage is that if one or more private keys is compromised or potentially compromised, you don't need to revoke and reissue all keys. Another, possibly more practical advantage is that I prefer to have a per-service persona that is not tied to other services. Shared public keys makes it easier to link together different accounts as belonging to the same person.
  • mook 10y ago
    Additionally, you can have substitutions in there: Host * IdentityFile ~/.ssh/%r@%h This is indeed better, as a compromise means only the private keys on the affected host are affected. That of course works better with a keypair per source/destination combination. Note that this _does_ cause issues sometimes, as it means your ssh-agent (you _are_ using one of those, right?) will have more keys than a typical auth attempt limit, and software that assumes trying all your keys before prompting for input is a sane thing to do will fail.
• Locke1689 10y ago
  What's the problem with ECDSA?
• morecoffee 10y ago
  Ed25519 is fast, but I don't think the speed is significantly faster to be an argument for using it. Running the borgingssl speed tool on a skylake mobile processor: Did 1083 RSA 2048 signing operations in 1017532us (1064.3 ops/sec) Did 29000 RSA 2048 verify operations in 1016092us (28540.7 ops/sec) Did 1440 RSA 2048 (3 prime, e=3) signing operations in 1016334us (1416.9 ops/sec) Did 50000 RSA 2048 (3 prime, e=3) verify operations in 1014778us (49271.9 ops/sec) Did 152 RSA 4096 signing operations in 1000271us (152.0 ops/sec) Did 8974 RSA 4096 verify operations in 1076287us (8337.9 ops/sec) ... Did 6720 Ed25519 key generation operations in 1029483us (6527.5 ops/sec) Did 6832 Ed25519 signing operations in 1058007us (6457.4 ops/sec) Did 3120 Ed25519 verify operations in 1053982us (2960.2 ops/sec) RSA key verification is still extremely fast. (also don't look at these numbers purely as speed, but as CPU time spent)
  • FullyFunctional 10y ago
    Not everyone is using Skylakes. My gateway is a Raspberry Pi (for historical and power reasons) and my most often used client is ARM based.
• developer2 10y ago
  Seriously, the default options to ssh-keygen should be all anybody needs. If you need to pass arguments to increase the security of the generated key, then the software has completely failed its purpose. Passing arguments should only be for falling back on less secure options, if there is some limiting factor for a particular deployment. There is absolutely no reason to pass arguments to ssh-keygen. If it is actually deemed necessary to do so, then that package's installation is inexcusably broken.
  • sillysaurus3 10y ago
    By default, ssh-keygen leaks info about your computer (``user@host''). Passing -C "" takes care of this. I just throw a script in my ~/bin folder called `keygen`: exec ssh-keygen -t rsa -b 4096 -C "" "$@"
    • hk__2 10y ago
      Why not just use an alias? alias keygen="ssh-keygen -t rsa -b 4096 -C ''"
      • liw 10y ago
        Aliases are per shell process. You need to reload your .bashrc (or whatever file you define aliases in) in every shell. Shell scripts are instantly available in all shell instances. Also, shell scripts can be invoked by shell scripts, which aliases can't.
        • hk__2 10y ago
          I agree, but for something as simple as that I’d prefer a script to use `ssh-keygen` instead of relying on the presence of a one-line script in the PATH.
    • Godel_unicode 10y ago
      If you're concerned about hostname leakage in your pubkeys, you're almost certainly doing something wrong.
• wyclif 10y ago
  the need to generate fresh ones to protect your privates much better Um, I'm pretty sure he meant privacy, not "privates." Time for an edit.
• otabdeveloper 10y ago
  Nobody is going to brute-force my git keys, especially when it's so trivial to gain access to the repos via social engineering.
• franciscop 10y ago
  Why not usimg this year as the name for the ssh? Then when you are using 2014.pub or 2013.pub you know it's time to upgrade
• aluhut 10y ago
  I wish this whole SSH business would be less complicated...
  • minitech 10y ago
    The defaults are actually fine; don’t worry. You don’t need to set a passphrase for your key, you don’t need to run an agent. Just ssh-keygen -t ed25519 and paste your public key into ~/.ssh/authorized_keys. `-t ed25519` is optional.
    • Latty 10y ago
      > You don’t need to set a passphrase for your key That's highly questionable advice. The passphrase is like two factor auth, it protects you if your private key ends up in someone else's hands. That's a risk you have to weigh up.
• ComodoHacker 10y ago
  >RSA 2048: yellow recommended to change Could someone provide a link with decent explanation why? Is it solely out of fear that it will be cracked soon on quantum computer?
• tete 10y ago
  Something I don't understand is the "hate" that RSA gets. Yeah, Elliptic Curves are promising, have benefits (smaller/faster). But RSA isn't broken, it is well understood, is "boring" (a plus on security, usually), has bigger bit sizes (according to people that know a lot more to me that's a plus point, regardless of EC requiring smaller ones, because of certain attacks), isn't hyped and sponsored by the NSA and isn't considered a bad choice by experts. Not too many years ago Bruce Schneier was skeptical about EC, because of the NSA pushing for it. Now, I also trust djb and i an sure that ed25519 is a good cipher and there are many projects, like Tor that actually benefit from it, increasing throughput, etc., but for most use cases of SSH that might not be the issue, nor the bottleneck. So from my naive, inexperienced point of view RSA might seem the more conservative option. And if I was worried about security I'd increase the bit size. Am I going wrong here?
  • fredgrott 10y ago
    Mathematically you do not need to determine primes to brute force break an RSA key...some fast GPUs and you can break some RSA keys daily...all I have to do is GUESS A PRIME and try it on the resulting encrypted message and measure the result for word and letter frequencies in modern human languages...Scary is it not?
  • zahllos 10y ago
    The bit size of the RSA modulus and the bit size of ECC keys aren't really comparable, as what matters is the number of operations required to break the primitive. A better comparison exists between multiplicative group crypto (DH/DSA) and their Elliptic Curve variants. In multiplicative group crypto there is a trivial, obvious mapping to the ring of integers (in less mathematical terms, "factorization makes sense"), so you can use techniques like Pohlig-Hellman (https://en.wikipedia.org/wiki/Pohlig%E2%80%93Hellman_algorithm https://en.wikipedia.org/wiki/Pohlig%E2%80%93Hellman_algorit...) and Index Calculus (https://en.wikipedia.org/wiki/Index_calculus_algorithm https://en.wikipedia.org/wiki/Index_calculus_algorithm). In Elliptic Curve groups we use, such a trivial mapping does not exist, although there are some special cases where you can achieve this (http://crypto.stackexchange.com/a/8344 http://crypto.stackexchange.com/a/8344). Consequently, larger numbers are needed for security in these cases (along with strong primes). The "bad press" RSA gets is likely due to the fact that in however many years of existence there have been a number of attacks on implementations - for example, side channel attacks, Bleichenbacher's attack on RSA PKCS#1_5 padding etc. Here's a survey: https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf . A simple explanation is that implementing RSA is a fun exercise for personal experimentation, but implementing RSA for use in the wild is fraught with difficulties. Ed25519 has some nice properties aside from the size of keys and signatures. It is deterministic, removing the requirement for cryptographically random (and therefore almost unique) k - if you forget this with plain ECDSA you end up in the Sony PS3 scenario. The provided software does not rely on indexes or branch instructions, removing timing issues in those cases and making the code constant time. It has what Bernstein calls "twist security" (https://safecurves.cr.yp.to/twist.html https://safecurves.cr.yp.to/twist.html). Ordinarily, an ECC algorithm should check that a calculated or received point, particularly where point compression is used, exists on the curve in question - however with DJB's "twist security" and in particular in ed25519 this is unnecessary, simplifying the job of the implementer. In other words, it is harder to get an implementation of ed25519 wrong. As for the NSA pushing ECC, more intelligent people than may have different views, but I believe that ECC in general is sound, taking into account the sum of our knowledge so far. As with any algorithm there are specific choices of curves and constants which weaken the setup and we have a case study where NSA pushed poor choices deliberately: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG . It comes down, therefore, to whether you believe the constants chosen for the NIST curves are "cooked" or not. I can't see any evidence to support this, but this doesn't mean it hasn't happened. However, Curve25519, Ed-448, Curve41717, FourQ and Brainpool curves are all curves designed outside the NIST system and not endorsed by the NSA and Bernstein includes in his security evaluations the concept of "rigidity", i.e. a full explanation of how curve parameters are generated (see https://safecurves.cr.yp.to/rigid.html https://safecurves.cr.yp.to/rigid.html) (although, apparently, there are some issues with Brainpool curve generation: https://bada55.cr.yp.to/brainpool.html https://bada55.cr.yp.to/brainpool.html). If you want to measure "time of life" as a measure of safety, using the general assumption that the longer something remains unbroken the safer it is, RSA certainly scores better in that sense (although ECC goes back to the 90s and Curve25519 to 2005, so have been around a while too) and for a correct, good, well vetted implementation of RSA I see no reason personally to stop using it, with the caveat that, as you've noticed, if you have a high throughput system, you get equivalent security more efficiently with ed25519. An interesting recommendation in the original article is to use smart cards for high assurance environments. I personally use an OpenPGP card (v2.1) and an authentication subkey on it acts as my SSH key. For this I use 4096-bit RSA keys - the OpenPGP v2.1 spec as implemented by this card does not support ECC at all, even though the actual hardware chip (http://www.basiccard.com/overview.htm http://www.basiccard.com/overview.htm) is capable of 512-bit ECC curves. The OpenPGP Card 3.0 standard includes ECC support but so far as I am aware no cards implementing it are available. The same is actually true in the JavaCard world; hardware support exists, but most JavaCard implementations you can buy are "limited" to 2048-bit RSA (If anyone knows differently I would love to know, please yell), which should be good enough for the moment but it would be nice to have some wiggle room. So to summarise, the "hate" that RSA gets is likely due to the number of times people have seen mistakes in implementations. That said, the article makes a good point regarding the strength of brute forcing your key passphrase if you are not storing your keys on smartcards. If you are going to regenerate your key, I see no reason not to use ed25519 as you will likely be using it for host authentication anyway (modern remote hosts likely generate ed25519 keys by default, rather than RSA). I'd use it on my smartcards if I could, since there the timing difference for a signature would be noticeable. I have multiple ssh keys and those not stored on a smartcard are all ed25519. If you are considering embedded environments or high throughput ones, or many signature checks, ed25519 makes even more sense.
• perlgeek 10y ago
  So I once read somewhere that RSA is simpler to implement than most other algorithms, and hence it's a safer choice than other algorithms, because weaknesses typically come from suboptimal implementation less than from the cryptographic algorithm. (Unless you use known-broken things like md5 or 3DES). And I think that was in the context of some DSA or ECDSA weakness, possibly a side channel attack or something similar. I forgot the details :( What are your thoughts on this? Should we focus more simplicity and robustness of the implementation, rather than just the strength of the algorithm itself?
  • FullyFunctional 10y ago
    Actually, if you ready DJB's fine papers he very much touches on this. Curve 25519 (now X25519) is specifically designed to avoid the pitfalls. The reference implementation is not too hard to understand, but granted the optimized versions are a little more delicate. Still, I imagine the optimized RSA implementations are no better.
• jkirsteins 10y ago
  Can anybody elaborate on the idea that for RSA <=2048 is potentially unsafe? Is it true? It seems that even 1024 bit keys haven't been factored yet, much less 2048, so why use anything else currently? https://en.m.wikipedia.org/wiki/RSA_Factoring_Challenge#The_prizes_and_records https://en.m.wikipedia.org/wiki/RSA_Factoring_Challenge#The_...
  • waynecochran 10y ago
    I want someone to explain this too -- the article does not give any strong evidence that RSA <= 2048 is unsafe.
• sztwiorok 10y ago
  very good post about security! many people still using RSA/DSA keys :/ some people are doing even worse things. Last week I saw one man who have shared his priv key by email message! QWERTY people have to grow up!
• deleted 10y ago
  [deleted]
• tarellel 10y ago
  Something I found resourceful while setting up SSH on a recent server is Mozilla's SSH Guidelines - https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://wiki.mozilla.org/Security/Guidelines/OpenSSH
• deleted 10y ago
  [deleted]
• eatbitseveryday 10y ago
  Maybe a more technical/comprehensive read is this[1] writeup, which I see some others have linked to. Prior HN[2]. [1] https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... [2] https://news.ycombinator.com/item?id=8843994 https://news.ycombinator.com/item?id=8843994