Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Seriously, Stop Using RSA (2019)

blog.trailofbits.com

Post reply on HN
Print view View original

21–30 of 125 posts

Re: Seriously, Stop Using RSA (2019)

#21

Post by upofadown »

cammikebrown wrote: post #19

Does OpenPGP use RSA?

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.

Re: Seriously, Stop Using RSA (2019)

#22

Post by jandrese »

armchairhacker wrote: post #2

“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 shortcut…

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.

Re: Seriously, Stop Using RSA (2019)

#23

Post by danenania »

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

Re: Seriously, Stop Using RSA (2019)

#25

Post by gotaquestion »

upofadown wrote: post #9

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…

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.

Re: Seriously, Stop Using RSA (2019)

#26

Post by stevenjgarner »

'"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?

Re: Seriously, Stop Using RSA (2019)

#27

Post by throwaway81523 »

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.

Re: Seriously, Stop Using RSA (2019)

#29

Post by not2b »

sivizius wrote: post #20

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…

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.

Re: Seriously, Stop Using RSA (2019)

#30

Post by spicybright »

YATA0 wrote: post #17
spicybright wrote: post #16

Earlier quoted context omitted.

Not sure what the joke is here.

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 HMAC…

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.

Post reply on HN