[HN Gopher] Seriously, Stop Using RSA (2019)
___________________________________________________________________
Seriously, Stop Using RSA (2019)
Author : pcr910303
Score : 97 points
Date : 2022-04-01 15:47 UTC (7 hours ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| EarlKing wrote:
| erdos4d wrote:
| > and the NSA doesn't like you using it.
|
| This is the best endorsement a crypto algorithm could have
| honestly.
| spicybright wrote:
| Unless you're really good at auditing code, why wouldn't you
| want to use something stronger?
|
| Memory managed languages are generally preferred for a lot of
| software because it's much harder to introduce memory leaks
| accidentally vs in something like C.
|
| Yes, C is fine, but if your goal is no memory leaks, you could
| be doing a lot better.
|
| I don't get why anyone would die on this hill over something as
| important as encryption. It's like using skeleton keys for your
| house door, because why would you be careless enough to not
| know when an intruder walks in?
| YATA0 wrote:
| Stop implementing your own crypto (poorly). Use HashiCorp Vault
| instead. Problem solved.
| StreamBright wrote:
| I was trying to generate a new ssh key with Vault. No dice. I
| needed a new cert for my SSL service. Vault let me down again.
| Could you help what am I doing wrong?
| YATA0 wrote:
| "I downloaded a script to run on Linux. Didn't work. I tried
| to install a package to help me check my battery. No dice."
|
| Sounds like you need to read the docs more closely or find
| someone that can manage Vault? Vault is some of the easiest
| security tech out there.
| prophesi wrote:
| From what I can tell, Vault doesn't handle generating SSH
| keys in the first place so reading the docs or finding an
| expert on the allegedly easiest security tech wouldn't be
| of much help.
| YATA0 wrote:
| >From what I can tell, Vault doesn't handle generating
| SSH keys in the first place
|
| Nor should it. That's managed by ssh-keygen. Hello UNIX
| philosophy!
|
| >so reading the docs or finding an expert on the
| allegedly easiest security tech wouldn't be of much help.
|
| If you're not an expert or feel confident in secops, find
| someone who is. Security is obviously something that
| shouldn't be taken lightly.
| spicybright wrote:
| Not sure what the joke is here.
| YATA0 wrote:
| There is no joke? Stop implementing your own crypto. Vault
| has transit encryption out of the box, among other things.
|
| "The transit secrets engine handles cryptographic functions
| on data in-transit. Vault doesn't store the data sent to the
| secrets engine. It can also be viewed as "cryptography as a
| service" or "encryption as a service". The transit secrets
| engine can also sign and verify data; generate hashes and
| HMACs of data; and act as a source of random bytes."[0]
|
| [0] https://www.vaultproject.io/docs/secrets/transit
| spicybright wrote:
| Oh. I thought it was because there are at least a dozen
| ways to securely encrypt/decrypt data, most of which are
| audited.
|
| Skimming their site they seem to offer some sort of
| encryption + service hosting? I don't see how this is much
| different than any of the other options out there. And not
| really an equivalent to using RSA as it looks to be tied to
| their hosting.
|
| I also tend to not trust for profit companies with things
| like this (esp. if it's closed source or I can't know what
| the servers actually run).
|
| Has this service been audited? Has it withstood against the
| US court system like veracrypt has multiple times? Do their
| founders have any history that goes against good data
| security?
|
| Your post sounds like an ad if I'm being honest.
| YATA0 wrote:
| > I thought it was because there are at least a dozen
| ways to securely encrypt/decrypt data, most of which are
| audited.
|
| Any yet people still implement on top of and leverage
| those lower-level libraries poorly.
|
| >Skimming their site they seem to offer some sort of
| encryption + service hosting?
|
| I believe they have a hosted SaaS solution now, but Vault
| is FOSS: https://github.com/hashicorp/vault
|
| >I don't see how this is much different than any of the
| other options out there.
|
| Vault manages your application-level encryption so you
| don't have to. That's a lot different than most of the
| options out there.
|
| >And not really an equivalent to using RSA as it looks to
| be tied to their hosting.
|
| It's not tied to their hosting. Spin it up on some VMs or
| a kubernetes cluster.
|
| >I also tend to not trust for profit companies with
| things like this (esp. if it's closed source or I can't
| know what the servers actually run).
|
| It's open source and HashiCorp... That's like saying you
| don't trust Linux with things like this because of
| RedHat.
|
| >Has this service been audited?
|
| Yes.
|
| >Has it withstood against the US court system like
| veracrypt has multiple times?
|
| Yes.
|
| >Do their founders have any history that goes against
| good data security?
|
| How do you not know who HashiCorp is?
|
| >Your post sounds like an ad if I'm being honest.
|
| Nope, just a happy user.
| NexRebular wrote:
| Been trialing Vault as a CA for internal use and so far
| everything seems to work great and setting it up with the
| documentation provided was quite easy. Furthermore,
| unlike some other FOSS developers they also provide and
| support illumos (Solaris) binaries for which I am truly
| grateful for.
| throwaway81523 wrote:
| Article is from 2016. It is a good article, but why does it say
| OAEP is notoriously difficult to implement? OAEP seemed very
| natural to me, and I "invented" it myself (long after it was well
| known to others, of course), i.e. the ideas in it weren't
| complicated. Am I missing something dumb?
|
| I do remember hearing that Victor Shoup found some kind of bug in
| the security proof, but it wasn't something of practical concern.
| cammikebrown wrote:
| Does OpenPGP use RSA?
| upofadown wrote:
| You get RSA by default with GnuPG. Since the signature method
| embodies your PGP identity you want to pick the method with the
| widest implementation. RSA is supported by TLS 1.3 for roughly
| the same reason.
|
| There are add on standards for various curves available for PGP
| should you want to mess around with them. GnuPG implements them
| all. Other implementations do not.
|
| Note that the encryption issues associated with an offline
| compatible system such as OpenPGP are different than online
| connected systems like TLS. The article was mostly talking
| about the sort of issues that crop up with an online connected
| system.
| sivizius wrote:
| RSA is bad, because developers do not implement it as specified
| and ECC is good, because most developers will not implement it
| themself, because they do not understand ECC and therefor use
| libraries? IMHO a huge advantage of RSA over ECC is it is easy to
| explain. After you have explained the different kinds of elliptic
| curves and their pitfalls, you have to explain the integrated
| encryption scheme to actually use it for encryption. But ok, you
| want hybrid encryption with RSA too, but in theory, you do not
| have to.
| not2b wrote:
| The article's argument is that because RSA is easy to explain,
| developers are more likely to roll their own and do it wrong.
| But that's mainly an argument against "roll your own", for
| those who aren't expert or aren't willing to take the time to
| learn all the pitfalls.
| gweinberg wrote:
| 1) Post needs a "2019". 2) Best comment inside was from Philip
| Zimmermann: "I agree. This is why I switched to El Gamal as the
| default algorithm for PGP version 5 in the late 1990s."
| [deleted]
| upofadown wrote:
| Here is a nice discussion of what happens when you don't validate
| your elliptic curve parameters properly:
|
| * https://research.nccgroup.com/2021/11/18/an-illustrated-guid...
|
| The highlight here is that in some cases, failure to properly
| validate gets an attacker the secret key material.
|
| Note all the conditional bits. Different curves have different
| properties and different issues. There are a bunch of different
| curves in common use while RSA pretty much always uses the same
| value for the parameter these days (RSA literally has just one
| parameter. The exponent.).
| Banana699 wrote:
| The article discusses this, the difference is that ECC
| parameters can be chosen before library-development time by
| expert cryptographers, all the developers have to do when
| actually developing the library is to generate random bits. The
| obviously complex mathematics of EC intimidate the non-experts
| away from trying to roll their own implementation and push them
| towards the most trusted expert implementation, while the false
| superficial simplicity of RSA seduce non-experts into
| greenspunning own implementations or using a greenspunned
| implementation without too much thought.
|
| >RSA literally has just one parameter. The exponent.
|
| How so? the 2 most important parameters are p and q, which have
| so many caveats and constraints on them that you lose track of
| them by the midpoint of the article, and you have to generate
| them privately so you can't offload this to non-affiliated
| cryptographers.
| fluoridation wrote:
| p and q are not parameters, they're the secret key. A
| "parameter" in this sense is a constant that defines the
| behavior of the algorithm that all users of the algorithm
| must agree on, otherwise they can't communicate.
| woodruffw wrote:
| In every RSA primer and cryptography reference that I'm
| aware of, p and q are considered parameters. Their nature
| as secret keys is merely a qualifier ("secret parameters").
| upofadown wrote:
| >The obviously complex mathematics of EC intimidate the non-
| experts away from trying to roll their own implementation and
| push them towards the most trusted expert implementation...
|
| My experience is that programmers are not so easily
| intimidated. If anything, complexity is an attractant...
| [deleted]
| gotaquestion wrote:
| Why would someone create their own parameters for deployment
| and not strictly research? There are plenty curves studied by
| academic experts out there that aren't even NIST.
| kuharich wrote:
| Past comments: https://news.ycombinator.com/item?id=20381779
| jchook wrote:
| Sounds like the author would agree it's fine to use RSA, so long
| as you use an audited library with a well-designed API that makes
| it easy to do the right thing, and hard to do the wrong thing.
|
| This makes me wonder, if we have an RSA library as good as
| libsodium, is ECC really a better choice than RSA?
|
| I love libsodium and tend to choose it, but ECC seems far more
| mysterious to me than RSA. Curve25519 is much newer, has more
| parameters, and could potentially have a backdoor (like it's
| precursor, P-256). It also has much smaller, fixed-size keys.
|
| RSA by comparison is elegant and simple to understand, with only
| one parameter. It's been in wide use since the 1970s. You can
| choose the key size.
| adgjlsfhk1 wrote:
| Comparing key size isn't really meaningful here because the
| main reason for moving away from RSA is that it needs way
| bigger keys to achieve the same security.
| d22 wrote:
| Keep in mind how much stress you would be putting on only
| having one implementation. In practice sooner or later someone
| would write another and using a needlessly complex encryption
| scheme can lead it to having bugs.
| 112233 wrote:
| Only key size. And public exponent. And padding algorithm. And
| prime generation algorithm. Remember what happened with
| Infineon's on-device generated keys?
| olliej wrote:
| "Seeming" "elegant" is not a good way of choosing cryptographic
| algorithms (this argument is also unfair to elegance of ECC).
|
| RSA has been in use since the 1970s and has been repeatedly
| shown to be extremely easy to introduce seemingly minor issue
| that completely break the crypto.
|
| Among the many issues are the belief that encryption is just
| P^^message%N. Which it is not - you must include padding, and
| doing that padding wrong also breaks the security.
|
| In general implementing RSA safely is very hard, then you also
| get to the the huge keysizes required for acceptable levels of
| security.
|
| An encryption scheme seeming elegant or understandable is not a
| sign of strength. Neither is age, as basic ciphers like Am+B%N
| have been used for thousands of years, but are trivially
| breakable.
|
| Furthermore, while RSA dates to the 70s, ECC still dates back
| to the early 80s IIRC.
|
| As for RSA being easy to understand, I'm not sure why you think
| ECC is hard to understand - you follow the specified addition
| operation and you get the correct result. I would argue it's
| even easier to intuitively understand than RSA, as the whole
| point is that you're both adding secret numbers together in
| such a way that you end up with the same total. This is unless
| you find the Chinese remainder theorem obvious?
|
| Honestly my current preferred encryption scheme is McEliece.
| Basically you generate an error correction code for a message
| such that it can correct half the bits in the message. The
| public key is your error correcting codes basis matrix
| multiplied by a permutation matrix to shuffle the bits around.
| Encryption is done by multiply the public key matrix by the
| message and then flipping half the bits. Decryption is simply
| inverting the permutation and performing the error correction.
|
| As a bonus, in addition to being simple McEliece has also been
| around since the 70s, encryption and decryption is extremely
| fast, it has withstood huge amounts of research and isn't
| broken by quantum computers. On the downside the keys are
| impractically large :(
| duskwuff wrote:
| > This makes me wonder, if we have an RSA library as good as
| libsodium, is ECC really a better choice than RSA?
|
| Yes, absolutely. Compare the key generation process, for
| example:
|
| RSA: generate two large prime numbers around half the size of
| your key, then make sure they aren't too close to each other,
| or share one of the primes with another RSA key someone else
| generated, or have certain mathematical relations to each
| other, or...
|
| ECC (specifically Curve25519): take 32 bytes of random data,
| set and clear a couple bits. Boom, done.
|
| Performing operations with ECC keys is also significantly
| faster, and constant-time implementations are much easier to
| develop and verify.
| LinAGKar wrote:
| >set and clear a couple bits
|
| What bits?
| duskwuff wrote:
| Clear the highest bit, set the next highest bit, and clear
| the three lowest bits. This process is known as "key
| clamping", and ensures that the private key is in the right
| range and is not vulnerable to a couple of specific
| attacks.
|
| https://neilmadden.blog/2020/05/28/whats-the-
| curve25519-clam...
| [deleted]
| kupopuffs wrote:
| ARe there even any valid reasons for implementing your own ?
| gleenn wrote:
| Is there any new concern that Curve25519 has been backdoored by
| the NSA? It looks like P-256 did a long time ago, and reading the
| Wikipedia article doesn't give that impression, wanted to check
| though.
| [deleted]
| JCBird1012 wrote:
| A backdoor in Curve25519 hasn't really been a concern, because
| unlike P-256, the parameters for the curve didn't come from
| NIST. Curve25519 is a djb
| (https://en.wikipedia.org/wiki/Daniel_J._Bernstein) special.
|
| So unless djb was secretly working with the NSA and willing to
| risk his reputation to backdoor a highly scrutinized elliptic
| curve, the risk is low.
| danenania wrote:
| EnvKey[1] moved from OpenPGP (RSA) to NaCl[2] for its v2, which
| recently launched.
|
| It's causing a difficult migration for our v1 users. Moving to a
| new encryption scheme is _not fun_ for a product with client-side
| end-to-end encryption.
|
| But within a year or so of releasing the v1, it seemed like the
| writing was on the wall for OpenPGP and RSA. I didn't want to go
| down with a dying standard.
|
| NaCl is _so much better_. In spite of the migration headaches
| that will likely cost us some users, I 'm very happy I made this
| decision. It's so much faster, lighter, and more intuitive.
|
| It's legitimately fun to work with, which I never thought I'd say
| about an encryption library after cutting my teeth on OpenPGP.
|
| 1 - https://github.com/envkey/envkey
|
| 2 - https://nacl.cr.yp.to
| frostburg wrote:
| This is all true, but reads funny to me because I've implemented
| an intentionally vulnerable version of RSA and still had issues
| getting timing attacks to work on modern hardware (due to lack of
| sophistication in my approach, I think).
| spicybright wrote:
| That actually sounds like a very enlightening exercise! How did
| you go about doing this? Did you just follow an RSA spec from
| somewhere?
| armchairhacker wrote:
| "RSA is bad because developers often don't implement it
| correctly, leading to vulnerabilities. Instead, use ECC, which
| can also be implemented incorrectly, but developers tend to do
| this less."
|
| The article raises some good points, but it really explains why
| you shouldn't use your own RSA or an unaudited third-party
| library. A good RSA implementation which has been audited by
| security experts and doesn't take shortcuts for performance would
| alleviate the OP's concerns.
| rakoo wrote:
| What is important is more a library where the easiest thing to
| do is correct, and making it really hard to make mistakes. Make
| the encrypt/decrypt function the only public api, with as few
| args as possible. Manage IVs under the hood so the user can't
| accidentally reuse them.
|
| That's the approach taken by NaCl, and arguably the only one
| worth considering.
| pvg wrote:
| The article doesn't say what your paraphrase says, though, and
| even less of what your next sentence says. The various RSA
| implementations with serious problems it brings up weren't all
| 'own RSA or unaudited third party library'.
| prophesi wrote:
| Two of the images in the article is
| https://i0.wp.com/blog.trailofbits.com/wp-
| content/uploads/20...
|
| And
|
| https://i0.wp.com/blog.trailofbits.com/wp-
| content/uploads/20...
|
| So it sounds like the main pain-point is improper
| implementation. Though the padding oracle attack is
| convincing to use something else, as it's necessary to pad
| yet still opens up to a different attack vector.
| pvg wrote:
| The article mentions various RSA implementations that have
| had problems. The other thing is, since they do audits and
| are telling you to avoid RSA, the advice obviously isn't 'a
| properly audited RSA is fine'. "it's actually ok to use
| RSA" is not a reasonable conclusion to draw from this
| piece.
| prophesi wrote:
| I think the crux of the argument is summed up here:
|
| > Developers could theoretically build an ECC
| implementation with terrible parameters and fail to check
| for things like invalid curve points, but they tend to
| not do this.
|
| So, it's just about trusting developers to implement a
| different algorithm properly.
| NateLawson wrote:
| This article is a good list of implementation flaws with RSA,
| both in parameter selection and protocols.
|
| However, I disagree with the recommendation to use ECIES. It
| has a separate MAC and encryption algorithm approach which is
| better served by AEAD algorithms these days.
| jandrese wrote:
| Maybe the article should say "use the security library that has
| the best developer documentation, as that gives the best
| chances of it working correctly."
|
| I'm not sure why, but documentation on crypto libraries tends
| to be noticeably worse than the documentation for any other
| library, pretty much assuming that the coder has already
| written their PhD thesis on implementing a cryptographically
| secure system and doesn't need the documentation to explain
| what anything is.
|
| And thus you have an endless stream of products that screw up
| setting the IV, because there was literally no guidance
| anywhere in the library about how you should handle it. Even
| big companies are made up of individual people and not
| everybody has the time to take graduate level courses on every
| single thing they're building before they build it.
|
| Having the library audited for correctness is of no help when
| the majority of problems arise from just using it wrong because
| the documentation was incomplete, vague, or even outright
| wrong/out of date.
| [deleted]
| stevenjgarner wrote:
| '"Seriously, Stop Using RSA" for Dummies' please!
|
| e.g. for a fullstacker who spins up the latest Ubuntu LTS then
| generates a pair of 4,096-bit RSA keys using default openssh-
| server set over a high-number TCP port, what should they be doing
| that is different?
| Chyzwar wrote:
| ed25519 can be generated as easily as RSA (ssh-keygen -t
| ed25519). Resulted keys are faster, shorter and possibly more
| secure than RSA.
___________________________________________________________________
(page generated 2022-04-01 23:01 UTC)