[HN Gopher] Seriously, stop using RSA: comments
___________________________________________________________________
Seriously, stop using RSA: comments
Author : upofadown
Score : 49 points
Date : 2022-04-02 16:55 UTC (6 hours ago)
(HTM) web link (articles.59.ca)
(TXT) w3m dump (articles.59.ca)
| oneplane wrote:
| Should both articles have been about implementing RSA rather than
| using it?
| eternityforest wrote:
| What kind of maniac would implement a crypto algorithm in
| production themselves, unless their last name is something like
| Schnier or Bernstein?
| throwaway81523 wrote:
| I've done it and feel ok about it. Others here have done it and
| done a good job. But yeah, there are different levels you can
| work at, you always have to be careful, and you have to know
| some theory in order to be able to even think clearly about the
| topic. I found Bellare and Rogaway's old lecture notes[0]
| demystified the subject for me a lot. There are some actual
| textbooks now that are more up to date and complete, though I
| don't happen to know of titles offhand.
|
| 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...
| eternityforest wrote:
| Any particular reason you'd ever do this? Obviously it kinda
| makes sense as a hobby project never used for something
| important... but in production?
| mc4ndr3 wrote:
| Simplicity in algorithm affords more capacity for studying
| implementation. Bugs are easier to find, even through very
| simple, automated fuzzing procedures, let alone formal
| verification.
|
| 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.
| tedunangst wrote:
| 20 years of RSA vulnerabilities and all they needed to do is
| fuzz it first!
| afiori wrote:
| As the saying goes: simple and easy are very different.
| throwaway81523 wrote:
| We're not talking about code bugs per se (program computes
| something different from what you intended). It's more like
| mathematical errors: you correctly compute what you intended
| to, but that turns out to be insecure for subtle reasons.
| Padding oracle attacks are an example that the article spent
| some time on.
| tptacek wrote:
| The author of this article has misunderstood the piece it's
| responding to, and doesn't appear to be familiar with the
| literature. For instance, this response is dubious about the
| security implications of primality testing bugs, claiming that
| Prime & Prejudice --- famously relevant to RSA --- had no
| apparent connection to it (presumably they read the abstract and
| not the study itself, which repeatedly mentions RSA). It just
| goes on like this.
|
| 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!
| throwaway81523 wrote:
| Yeah I think you are right, the article is weak. Even the first
| implementation advice it gives doesn't look right to me, if
| interpreted the obvious way:
|
| > 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.
| upofadown wrote:
| I guess this could use a bit of context (author here). This is
| part of a series of PGP advocacy articles [1]. There was a post
| of "Seriously, stop using RSA" on here yesterday that prompted me
| to look at my article again. A better article was possible so I
| rewrote it and posted it.
|
| So, yes, this is very focused and partisan by design. There is a
| larger discussion about RSA that I chose to ignore.
|
| [1] https://articles.59.ca/doku.php?id=pgpfan:index
| klabb3 wrote:
| One reason I like ECC (Curve25519 in particular) is speed and
| size of generated keys and signatures. It is a lot easier to
| compose crypto with business logic when you can basically assume
| instantaneous key gen (RSA takes a non-deterministic amount of
| ~seconds) as well as 32-byte signatures that are practical even
| for short messages (as opposed to 256-512 bytes).
| oh_my_goodness wrote:
| Either most of this is not really a response to the article, or
| I'm really misunderstanding something here.
|
| (The article may be good or bad, I don't know.)
| cowsandmilk wrote:
| ?? Half this blog post is quotes of the original article and
| the other half are direct responses to the quoted sections.
| [deleted]
| jchw wrote:
| I'm a bit miffed after just a couple paragraphs. My reading of
| the original article was that the issue of people feeling tempted
| to implement RSA was just exacerbating the problem of how
| difficult it is to implement RSA securely.
|
| 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.
| nwallin wrote:
| > A bad RSA implementation leads to weak cryptography, but a
| bad ECC implementation often leads to something that doesn't
| work at all.
|
| 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.
| Retr0id wrote:
| ECDSA in particular is very easy to fuck up (which Sony
| famously did - although there are plenty of examples of more
| subtle sidechannel attacks in, for example, the OpenSSL CVE
| history).
|
| Although, that's more of a criticism of ECDSA than it is of
| ECC as a whole.
| marcan_42 wrote:
| ECDSA is easy to fuck up due to needing a "random" number
| for signatures (among other things, but that's the one Sony
| did and many others have since). Thankfully, we've figured
| out an easy fix for that: just hash the private key and the
| message, and use that instead of the randomness. That's in
| the spec for ed25519, so unless you're completely ignoring
| chunks of the spec (which would be unlikely to work for an
| algorithm like this, and wouldn't pass test vectors) you're
| probably fine on that front if you use it, even if you're
| reimplementing it.
| [deleted]
| Retr0id wrote:
| It's not just the randomness requirement, but also the
| requirement that k (the "random" nonce) remains secret.
| Without a sufficiently constant-time implementation, you
| leak information about k through timing sidechannels -
| and with clever tricks like lattice reduction you can
| recover the key with surprisingly little information.
| [deleted]
| tptacek wrote:
| How old does something have to be before it stops being "the
| new hotness"?
| throwaway81523 wrote:
| ECC is also easy to mess up, especially the NIST curves. Plenty
| of subtle stuff to get wrong.
| [deleted]
| tptacek wrote:
| Curve25519 is significantly harder to mess up than RSA. You
| can go either way on the NIST curves vs. RSA, but at an
| architectural level there's simply less that goes around with
| the _model_ of ECC than with RSA, which directly exposes an
| easy-to-use (and treacherously easy to fuck up) encryption
| transform. I wouldn 't implement with the NIST curves at all,
| but if you asked me to pick between them and RSA, I'd still
| take P-256 over RSA.
| jchw wrote:
| That was acknowledged and accounted for in the original
| article. But given that we have curves that we believe are
| safe, I'm not sure this is an issue, at least any more so
| than relying on known-good ranges for parameters in any
| cryptosystem...
| dang wrote:
| Recent and related:
|
| _Seriously, Stop Using RSA (2019)_ -
| https://news.ycombinator.com/item?id=30879442 - April 2022 (101
| comments)
___________________________________________________________________
(page generated 2022-04-02 23:01 UTC)