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

41–50 of 125 posts

Re: Seriously, Stop Using RSA (2019)

#41

Post by fluoridation »

Banana699 wrote: post #32
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…

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

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.

Re: Seriously, Stop Using RSA (2019)

#43

Post by adgjlsfhk1 »

jchook wrote: post #34

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

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.

Re: Seriously, Stop Using RSA (2019)

#44

Post by prophesi »

YATA0 wrote: post #42
StreamBright wrote: post #18

Earlier quoted context omitted.

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?

Quoted post unavailable.

No post body was provided.

Re: Seriously, Stop Using RSA (2019)

#45

Post by NateLawson »

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…

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.

Re: Seriously, Stop Using RSA (2019)

#46

Post by d22 »

jchook wrote: post #34

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

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.

Re: Seriously, Stop Using RSA (2019)

#47

Post by YATA0 »

prophesi wrote: post #44
YATA0 wrote: post #42

Earlier quoted context omitted.

Quoted post unavailable.

Quoted post unavailable.

>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.

Re: Seriously, Stop Using RSA (2019)

#48

Post by 112233 »

jchook wrote: post #34

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

Only key size. And public exponent. And padding algorithm. And prime generation algorithm. Remember what happened with Infineon’s on-device generated keys?

Re: Seriously, Stop Using RSA (2019)

#49

Post by YATA0 »

spicybright wrote: post #30
YATA0 wrote: post #17

Earlier quoted context omitted.

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

> 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.

Re: Seriously, Stop Using RSA (2019)

#50

Post by duskwuff »

jchook wrote: post #34

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

> 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.

Post reply on HN