1. 69
  1.  

  2. 6

    I notice my SSH key is RSA, because that seems to be the default generated by OpenSSH’s ssh-keygen. I usually trust the OpenSSH developers to make good decisions, so not sure what to think here. Should I generate a new key using a different system? Or is this just about not implementing RSA yourself, while using it through OpenSSH is fine, because the OpenSSH developers have avoided these pitfalls?

    1. 14

      You should think about using ed25519 keys if you’re going to make a change, but it’s not urgent.

      1. 4

        It’s not such a problem that you need to go change your keys right now, but next time you’re making one, choose ed25519 instead. It’s faster than RSA, and the public key string is much smaller.

        1. 3

          The latter. Your keys (assuming they’re at least 2048-bit) are fine. If you’re implementing RSA yourself, there’s lots of room to screw things up, but done correctly, the cryptography is very secure, and OpenSSH is probably one of the most security-audited pieces of software in existence.

          1. 2

            Long-battletested implementations are fine.

          2. 5

            I was already hooked by the smashing of a SecurID token at the start of the talk.

            1. 6

              A shame that a well laid-out explanation of a good case will slide rapidly into obscurity due to someone’s.. avant-garde choice of article title.

              1. 20

                People have been sounding the alarm about RSA in more reasoned language for years. Time for a new tact.

                1. 9

                  I totally agree. But I also think it’s really funny that we’re basically saying, “All right gentlemen, we’ve tried everything in our arsenal, and nothing’s worked. It’s time to use… the fuck-word…

                  1. 2

                    Agreed.

                    Time for a new tact [better communication]

                2. 3

                  I don’t really think you’re right. I read it specifically because of the title; I have to admit, I enjoy a good rant more than someone’s academic musings on a topic I don’t understand much of.

                  Ended up reading the whole thing, and like you, I found it to be a well laid-out explanation. It definitely changed this non-cryptographer’s view of RSA.

                3. 3

                  Padding oracle attacks everywhere

                  That is not a unique feature of RSA. Padding oracle attacks have affected AES implementations, and, unless I’m completely misunderstanding the nature of the attack, can have the same effect on most cryptographic algorithms. This seems like the author was just padding out the article near the end.

                  Seriously, stop using RSA

                  Use libsodium, or something else that abstracts away the entire cryptosystem and just asks you to feed it bytes. It can still use RSA under the hood as long as it uses secure parameters.

                  1. 6
                    • AES-CBC needs padding, but AES-CTR does not. Neither does Chacha20. So if you’re using the AES-CGM or ChaPoly authenticated encryption schemes, you won’t really need padding.
                    • Hashes (polynomial or regular) do padding internally, but that stuff tends to be naturally constant time (more specifically, only dependent on the message’s length, which is not secret).
                    • Then, elliptic curves don’t use padding (not at all for key exchanges, and only in the hash function in signatures).

                    Padding is actually pretty easy to avoid.

                    1. 3

                      AES is symmetric, that’s not in the same category. Elliptic curve stuff (that libsodium uses) does not need padding.

                    2. 2

                      Just thought I’d play devil’s advocate…

                      It’s important to recognize that in none of these cases is it intuitively obvious that generating primes in such a way leads to complete system failure. Really subtle number-theoretic properties of primes have a substantial effect on the security of RSA. To expect the average developer to navigate this mathematical minefield severely undermines RSA’s safety.

                      Not in my opinion. The way I see things, when you take a shortcut to build your software, you are opening up a shortcut for attackers to use. There are cases where a little due diligence can yield a lot of safety; but cryptography isn’t one of them. If you’re developing an application, use a thoroughly tested library; if you’re developing a library, take a step back and ask yourself why you’re taking shortcuts while developing a vital piece of security software. <end-of-throwing-stones-from-a-glass-house>

                      People might call me out here and point out that normally when setting up RSA you first generate a modulus, use a fixed public exponent, and then solve for the private exponent. This prevents low private exponent attacks because if you always use one of the recommended public exponents (discussed in the next section) then you’ll never wind up with a small private exponent. Unfortunately this assumes developers actually do that. In circumstances where people implement their own RSA, all bets are off in terms of using standard RSA setup procedures, and developers will frequently do strange things like choose the private exponent first and then solve for the public exponent.

                      Why isn’t this already a standard part of randomness/cryptography libraries? Or is it, and it’s hidden away or conveniently ignored?

                      1. 17

                        RSA is simple enough it can be implemented after reading the Wikipedia page. I don’t need a library. I can write it myself. I am very smart.

                        1. 5

                          It’s in that perfect happy place where the underlying mathematics can be understood by any math undergrad (or even some enterprising high schoolers), but the pitfalls and ways to screw it up are many and subtle enough to require an expert in cryptography to reliably avoid.

                            1. 1

                              Can’t tell if you’re trying to be sarcastic here, but if you are, then I think we’re talking past each other. I’m saying people should know, or be taught, not to write these things themselves. Maybe that Wikipedia page you mention should include a section about the breaches created by misconfigured or badly implemented RSA. This particular topic is new to me, and I don’t appreciate being greeted with upvote-baitey snark.

                              1. 2

                                There’s an interesting cautionary tale that’s relevant: Bruce Schneier’s 1994 Applied Cryptography, which so effectively and clearly describe various tools and systems in crypto that many developers began implementing them from scratch. This was addressed in the quasi-follow-up Cryptography Engineering (2010) but left echoes for years in the form of now-defunct PHP sites all over the web with homebrewed implementations of MD5, block ciphers, etc.

                          1. 2

                            I’m more than happy to support this but … how? Does nginx or Let’s Encrypt even support something other than RSA?

                            1. 3

                              nginx has supported ecdsa forever. LE for some months, almost a year I believe.

                              1. 3

                                I looked into this in some more detail, and it seems like LE’s certbot doesn’t support ECDSA, but some of the other implementations do (like acme.sh). Still, the other concern is these are NIST approved curves, none of which are safe according to this. 👎