Seriously, stop using RSA: comments
articles.59.ca
articles.59.ca
This is part of a pattern with this author. They're extremely attached to PGP. PGP uses RSA. Therefore: RSA must be fine. Recurrence of the same pattern: PGP doesn't use authenticated encryption. Therefore, authenticated encryption must not be important, or maybe it's even a negative. There's another example somewhere in the comments here about forward secrecy being overrated. (I can cite, but you should just take my word for it that these takes have been shared here).
It's frustrating, because the pattern isn't super clear in isolation (though this response actually mentions PGP as the impetus for the response) and, if you don't work in the field, it might not be clear how far these takes stray from cryptographic engineering orthodoxy. It's also frustrating because in general, we're not supposed to write things like this on HN --- a list of floridly bad previous comments from this author would be way over the line --- so one has to sort of tiptoe around the edges of the guidelines to find a way to describe what's going on here.
Anyways, caveat lector.
Hats off for describing Boneh's fault attack paper as "completely theoretical", though! Bold!
> Normally for RSA you pick 2 random numbers and then find a prime close to each.
I.e. if you pick a number and then search upwaard til you find a prime, that gives a non-uniform distribution on the primes in that range. You instead want to pick a random number, and if it's composite, throw it away and pick another random number til you get a prime. Then repeat to get second prime.
(This is a relatively recent result. And as I mentioned in my other comment, this is not a defense of the article!)
The point of the Prime and Prejudice paper is, in effect, that the Miller-Rabin primality test should only be applied to random prime candidates, not adversarially chosen ones. The reason is: for a random composite, each M-R iteration has probability roughly 1/4 of revealing that the number is indeed composite. But it is possible to find composites that fool M-R with high probability. The upshot is: if an adversary is proposing primes to you, be very careful about using M-R!
For RSA key generation, unless you're worried about your RNG (in which case you're sunk anyway, to a first approximation), candidate primes are not adversarially chosen. So, as this article says, it does not appear that Prime and Prejudice is an issue for RSA key generation.
As further evidence for this, the Prime and Prejudice paper does not talk about vulnerabilities in RSA key generation. The issues that it describes have to do with validating prime-field DH parameters provided to a client by a potentially adversarial TLS server. As far as I can tell, the P&P paper only mentions RSA three times: twice as name-checks and once in the name of a library.
This isn't a defense of any other claim in the article. But as far as I can tell, P&P is not an issue in the context of RSA key generation.
You stopped quoting too soon. I described it as a "completely theoretical hardware attack". In practice it would have to be some sort of glitch attack capable of causing actual bit flips. My point is that it has nothing to do with RSA implementation as it was described in the article.
I am not a cryptographer. I’d be rather cautious about implementing my own cryptography at all, less with my own code implementing the primitives. That said, Trail of Bits makes a compelling argument, that, in my reading, RSA is harder to get right in subtle ways, whereas ECC is just hard to grok period. A bad RSA implementation leads to weak cryptography, but a bad ECC implementation often leads to something that doesn’t work at all.
This, alongside other benefits of ECC like smaller key sizes for similar cryptographic security, faster and simpler key generation, more idiot-tolerant properties, etc. makes ECC an obvious choice even disregarding if you can implement RSA. It’s just that people like to choose RSA because they feel like they understand it, but the truth is they only understand the surface-level basics. (To be fair, me too. Though I feel I also can grok some surface-level basics of some ECC-based algorithms, too.)
Feel free to flame me for not reading the article entirely; I definitely earned it. But that opener made me not want to, sorry.
Bad RSA implementation => weak cryptography. We agree on that.
Bad ECC implementation => doesn't work. We agree on that.
Working ECC implementation => strong cryptography. We do not agree on that. I think that there are many subtle ways to make a weak ECC implementation.
At the end of the day, I am never going to roll my own crypto implementation. (Well, actually, I already have, but it was for "hey how does this work. oh it works like this. neat!" and promptly deleted the code afterwards) I'm always going to use libsodium or nss or openssl or gnupg or or or. So the fact that RSA is harder to implement correctly than ECC is... well that kinda doesn't matter to me. Implementing it correctly isn't my job. All I need to do is include someone elses' library. And I can be about as sure that libsodium or openssl has implemented the proper precautions to make RSA secure. So the fact that RSA is hard -- well, it's kinda irrelevant.
FWIW, I tend to default to ECC, because ECC is the new hotness, and that appeals to me for entirely superficial reasons. I'm just saying that if you're going to say that RSA is bad, you should have the right reasons for saying so.
Although, that's more of a criticism of ECDSA than it is of ECC as a whole.
The “easier to verify correctness” part very much matters to me even if I’m not writing the code.
Bugs scale in frequency according to total source line count. Don't expect professionals to write perfect code, especially as complexity grows.
Simplicity of algorithm is critical for peer review of the implementation, as the pool of reviewers is incredibly small. It's one thing to prefer community vetted implementations, but the implementation cannot be blindly trusted by everyone--that would be involve the logical fallacy of an appeal to authority.
Seriously, Stop Using RSA (2019) - https://news.ycombinator.com/item?id=30879442 - April 2022 (101 comments)
So, yes, this is very focused and partisan by design. There is a larger discussion about RSA that I chose to ignore.
(The article may be good or bad, I don't know.)
For ECC with NIST curves, Menezes, Vanstone, et al have a book that gives very explicit step by step implementation instructions.
[0] https://web.cs.ucdavis.edu/~rogaway/classes/227/spring05/boo...
Crypto primitives are actually not that dangerous to implement, since there will usually be test vectors and/or other implementations you can check against. You get in trouble if you try to develop your own protocols, make mistakes with parameter selection, and that sort of thing.
Added: Here is some code that needs to be written, if it hasn't been already:
* TLS stack written in Rust, so we don't have to keep using the legacy OpenSSL stack. Or similarly, in Ada.
* SSH stack, same same.
* High speed primitives in RISC-V assembly language, in multiple versions optimized for different architecture implementations
* Lots of weird special primitives used in things like old fashioned payment protocols. I dealt with this somewhat when working on POS terminals.
* Hardware implementations in VHDL and Verilog
* Etc.
I'd feel comfortable working on the first two of the above. Someone has to do it, and we can't always get DJB to do everything, so that leaves people like us.
Still, as much as I think C/C++ are garbage languages, I'd rather have OpenSSL than any alternative that didn't have review by security specialists.
Some fraction of general programmers may also have that kind of experience, but it's like handymen doing plumbing. Some unlicensed people have the skills, but if you yourself don't know the subtle pitfalls of plumbing, how can you evaluate their work?
I don't know what side channel attacks are possible and what ones aren't. I don't know what instructions have hidden power analysis attack implications.
I could study for months, and try to learn those things, but I could also just use OpenSSL, since it's free. Less effort AND probably safer.
The specialists will get to the Rust redo eventually, I'd rather let them handle it, just like they'd probably rather let me fuss with boring web UI framework version upgrade issues.
Part of the reason C programs need such intense review and shakedown is that C itself is so hazardous. When you write in better languages, issues tend to settle out faster.
I don't claim to be a major crypto wizard like DJB, but I've been at it a while, have been in the industry, know other implementers shipping significant products and can see that they do the same type of stuff that I do. The big brains in the field are e.g. mathematicians designing primitives. Merely implementing them is just engineering and following specs and standards. It's much less big of a deal.
If you study those notes, you'll understand how cryptographers think, how security proofs work, and how modern protocols (though usually not older ones) are designed so that the proofs come along with them. Instead of having to rely on impossible-to-capture shades of finely tuned judgment, you get actual theorems that are bulletproof. So if you have a reasonable math background, you know what proofs are, you know that if your thing is done right then (against the designed-for threat model) your stuff is secure, and you know what it means for your thing to be done right.
So that just leaves executing the latter, which is still the usual error-prone engineering. But good languages and software (look e.g. at Cryptol on galois.com) can help with that too. Most OpenSSL CVE's lately are things like heap overflows rather than crypto misdesign. Coding in Rust is supposed to eliminate those (idk if it always does in practice).
I can't prove in a few sentences that this isn't false confidence but I think there is something to it. At the very least, understanding some theory brings a great improvement to one's clarity of thought.
It's definitely possible for an individual do this stuff, if it can be mathematically proven(My math level is a bit below grade school algebra so I can't really evaluate it there), proofs don't lie, regardless of who proved them, they are in themselves a way better authority than any human.
But anyone who truly does learn all that IS one of those rare crypto experts, and there aren't that many. Who can code review? If someone leaves the team, does anyone else have that level of skill to be able to maintain it?
It might be worth learning crypto for the same reason as any of the other random things they say coders should know, like Haskell and LISP or the dreaded FORTH though.
As for threat models, NaCl and OpenSSL don't magically mitigate against currently unknown threats. Really paranoid crypto is usually wrapped in HSM's (electromagnetically shielded, tamper resistant etc.) in the hope of blocking some of that.
Yeah, this is the really scary part. It's also the part not amenable proofs.
I had to implement some crypto primitives at one point in my career (for a boring combination of legal and technical reasons). Yes, I was nervous, but you pay attention to details and take careful stock of the tools you available (e.g. what's my environment's constant-time comparison function? what's my CSPRNG?) and it's not really harder in the end than implementing lots of other algorithms, you just feel like it is because the stakes are higher. As mentioned many times in this thread, some of the primitives today are also really hard to mis-implement!
But those were also part of a system that had to be secure. That was the terrifying part, because our threat models were relatively unique. But this is also the part that developers do all the time without thinking about it - any time you roll a middleware that looks directly at a JWT, or your own web session bootstrapping, or read a regexp from a user, you're committing the same kind of sin. Having a PhD in lattice reduction on-board for that isn't any help. Having security experts helps a lot for this, but when you have them they're not applying any complex math, they're just exceptionally good at getting into a Red Team mindset.
tl;dr: If you're debating implementing your own ed25519, you're probably already way too far down the rabbit hole to instead grab libnacl and claim some pride that you didn't "roll your own crypto"; even if you take libnacl at that point you've already made most of the security decisions that will make or break you.
I say that just to point out that your confidence is probably not false, and neither is everyone elses lack of confidence in touching crypto.
1. Writing a HW crypto module in an HDL like Verilog or VHDL where one doesn't exist or you don't have access to it.
2. Adding support for a given algorithm on an architecture or platform where none of the other implementations will work (due to either arch differences, memory/cpu constraints, exotic HW, etc).
I can't think of why you'd write such a thing and put it in production otherwise. It's just too expensive to get wrong IMHO however I'd love to be proven wrong.
I'm not sure what serial rapist thing you're referring to, I assume Appelbaum's connection to DJB? I hadn't heard of that one, and that is in fact highly disgusting. And especially disturbing considering the fact that anyone involved woth security or privacy tends to think of themselves as some kind of hero of global freedom... and then to do that...
I still definitely wouldn't trust crypto done by a nonspecialist, but it does seem like the specialist community has problems.
Then there's hundreds and maybe thousands responsible for implementing cryptographic systems and protocols using those primitives. Most of them could also implement such primitives correctly with a little more effort, and many of them will do a better job making these systems practically safe than the first group would have.
And there's another large group who need to learn how to do this, because relying on a cadre of curmudgeonly aging white men, several already of extremely dubious moral character, isn't exactly a sustainable strategy for software development.
You don't know most of their names. They do mostly fine work. Please, end this rockstar shit.
There are hundreds and thousands of them, sure, and I don't know their names, but they're still security professionals.
You may well be every bit as good as them. But I have no way to verify this. If I used code from someone not well known I would have no way to justify it. Even if I taught myself crypto(Which I wouldn't really consider the best time investment), I could be lying just like you could.
Someone else on the team would need to deeply understand it to review it. But in reality most people would probably either just rubber stamp it or say "Go use libnacl instead".
Protestware has shown the social process of trust isn't perfect, but it's all we have unless we get a crypto expert on every team.
I'm not particularly privacy conscious. I don't have a separate network for IoT. Using primitives developed by specialists is just a very easy low hanging fruit.
People of dubious character is... just software development in general really.
It's even worse in other areas of software. With crypto at least you have the option to implement it yourself, for better or worse, with large applications you just physically can't unless you want to spend years on it.
But there's still people like Lenore Blum though, it's not all men, and I don't know of any nastiness she's perpetrated.
Until people stop writing vulnerable code, it's pretty hard to believe anyone who says their code is safe without tons of auditing.