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

101–110 of 125 posts

Re: Seriously, Stop Using RSA (2019)

#101

Post by nwallin »

willis936 wrote: post #76
cantrevealname wrote: post #73

There's an extremely interesting rebuttal that appears as a comment in the original article. I'm going to quote it below for the benefit of HN readers. /QUOTE Bob, February 28, 2020 at 12:15 KEEP USING RSA! This article is misleading to make it appear that RSA is not secure, but only the only evidence presented is improper implementation. Properly implemented RSA has been proven secure and unbreakable by the NSA with…

Sounds like tinfoil hat. Afaict RSA is simpler to crack with quantum computers than ECC.

> Afaict RSA is simpler to crack with quantum computers than ECC.

RSA requires 2n qubits to crack, ECC requires 6n. Since the normal RSA key is 2048 bits, and the normal ECC key is 256 bits, RSA requires a 4096 qubit quantum computer, and ECC requires a 1536 qubit quantum computer. If you use 4096 bit RSA and 512 bit ECC keys, this becomes 8192 qubits and 3072 qubits respectively. I'm not aware of any ECC curves larger than 512 bits.

Ultimately, both are broken in a post-quantum world. However, in the interim-quantum world, where quantum computers exist but are noisy and unreliable, RSA is safer.

Re: Seriously, Stop Using RSA (2019)

#102

Post by emj »

nullc wrote: post #71
thaumasiotes wrote: post #67

Earlier quoted context omitted.

> (key[31]&63)|64 You confused me here; this looks like you're clearing the highest bit and then setting the highest bit... in a 7-bit integer. Of course it makes more sense that you're clearing the two highest bits and then setting the second-highest bit of an 8-bit integer, which is indeed the same thing as clearing the highest bit and then setting the second-highest bit. But why have you written it to fiddle the s…

just because 63 was a shorter constant to type than 127. Hex would have been longer due to the prefix. :P

Thank you for that self analyzing! I got lost on that part, so will now stop writing ping 127.1 just to save four bytes. I've always felt that people learnt things by seeing that, but now I know I'm too lazy to bother learning myself.

Re: Seriously, Stop Using RSA (2019)

#103

Post by marcus_cemes »

danenania wrote: post #23

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…

I'm not familiar with NaCl, websites that don't seem to have been updated in 7 years (version states 2016?) make me a little suspicious about the future viability of said projects. Perhaps it's not something that needs to be updated very frequently, but my knee-jerk reaction is that it looks abandoned, especially considering that they have an "upcomming features" section.

What made you choose it? Could PGP/GPG with ed25519 keys not have been sufficient? What makes NaCL "fun to work with"? For me, fun to work with would be Age [1] or Ring [2] with a elegant and well designed API. I'm also aware that the older something is, the more likely it has undergone peer review and security audits, unlike new Rust crypto libraries.

[1]: https://github.com/FiloSottile/age [2]: https://github.com/briansmith/ring

Re: Seriously, Stop Using RSA (2019)

#104

Post by _0ffh »

a1369209993 wrote: post #81
duskwuff wrote: post #74

Earlier quoted context omitted.

> The odds of "accidentally" getting two factors that are unduly close... ... are actually pretty high with some poorly conceived key generation algorithms. There are other ways that RSA key generation can be weak, such as ROCA ( https://en.wikipedia.org/wiki/ROCA_vulnerability ).

> ... are actually pretty high with some poorly conceived key generation algorithms. To be fair, that's what they said : > > a naive approach works fine - it's just that doing this is slow and when people try to do something fast they keep making keys which fail the criteria you listed. The naive way to generate a RSA key is to pick a uniformly random 1024-bit (or per your security parameter) integer, test if it's pr…

>any optimization that doesn't exactly and exactingly preserve the distribution almost always turns out to introduce exploitable vulnerabilities

Not a crypto expert, but aren't there changes to the distribution that you actually want to make, like having a lower size limit for each of the factors?

Re: Seriously, Stop Using RSA (2019)

#105

Post by aaronmdjones »

stouset wrote: post #69
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,…

> and could potentially have a backdoor (like it's precursor, P-256) P-256 is not known to or even suspected to have any backdoors.

NIST P-256 (and ECDSA in general, to some extent) is widely suspected to have been subverted by NSA, as outlined in the first link in octoberfranklin's response, page 16 of [1], and [2].

[1] https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf

[2] https://blog.cr.yp.to/20140323-ecdsa.html "I have a different view. I blame this attack on the ECDSA designers [https://www.nsa.gov/]."

Re: Seriously, Stop Using RSA (2019)

#106

Post by zenexer »

marcus_cemes wrote: post #103
danenania wrote: post #23

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…

I'm not familiar with NaCl, websites that don't seem to have been updated in 7 years (version states 2016?) make me a little suspicious about the future viability of said projects. Perhaps it's not something that needs to be updated very frequently, but my knee-jerk reaction is that it looks abandoned, especially considering that they have an "upcomming features" section. What made you choose it? Could PGP/GPG with e…

NaCl is a reference implementation by djb[1], but libsodium is more widely used[2] and offers the same API.

[1]: https://en.wikipedia.org/wiki/NaCl_(software)

[2]: https://doc.libsodium.org/libsodium_users

Re: Seriously, Stop Using RSA (2019)

#107

Post by dolni »

willis936 wrote: post #76
cantrevealname wrote: post #73

There's an extremely interesting rebuttal that appears as a comment in the original article. I'm going to quote it below for the benefit of HN readers. /QUOTE Bob, February 28, 2020 at 12:15 KEEP USING RSA! This article is misleading to make it appear that RSA is not secure, but only the only evidence presented is improper implementation. Properly implemented RSA has been proven secure and unbreakable by the NSA with…

Sounds like tinfoil hat. Afaict RSA is simpler to crack with quantum computers than ECC.

After Snowden blew the whistle on government domestic surveillance, THIS rises to the level of tinfoil hat for you?

Re: Seriously, Stop Using RSA (2019)

#108

Post by a1369209993 »

_0ffh wrote: post #104
a1369209993 wrote: post #81

Earlier quoted context omitted.

> ... are actually pretty high with some poorly conceived key generation algorithms. To be fair, that's what they said : > > a naive approach works fine - it's just that doing this is slow and when people try to do something fast they keep making keys which fail the criteria you listed. The naive way to generate a RSA key is to pick a uniformly random 1024-bit (or per your security parameter) integer, test if it's pr…

>any optimization that doesn't exactly and exactingly preserve the distribution almost always turns out to introduce exploitable vulnerabilities Not a crypto expert, but aren't there changes to the distribution that you actually want to make, like having a lower size limit for each of the factors?

> aren't there changes to the distribution that you actually want to make

Yes, but that isn't a optimization, it's a deliberate change in semantics.

> like having a lower size limit for each of the factors?

For some reason, a annoying amount a cryptography literature uses "1024-bit integer" to mean "a (arbitrary-precision) integer whose most significant set bit is in position 1023". I probably should have phrased that better to avoid confusion with "a integer stored in 1024 bits of memory".

Re: Seriously, Stop Using RSA (2019)

#109

Post by frostburg »

spicybright wrote: post #12
frostburg wrote: post #5

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

That actually sounds like a very enlightening exercise! How did you go about doing this? Did you just follow an RSA spec from somewhere?

I mostly followed lecture notes on the subject and a few papers on issues like prime checking.

Re: Seriously, Stop Using RSA (2019)

#110

Post by _0ffh »

a1369209993 wrote: post #108
_0ffh wrote: post #104

Earlier quoted context omitted.

>any optimization that doesn't exactly and exactingly preserve the distribution almost always turns out to introduce exploitable vulnerabilities Not a crypto expert, but aren't there changes to the distribution that you actually want to make, like having a lower size limit for each of the factors?

> aren't there changes to the distribution that you actually want to make Yes, but that isn't a optimization, it's a deliberate change in semantics. > like having a lower size limit for each of the factors? For some reason, a annoying amount a cryptography literature uses "1024-bit integer" to mean "a (arbitrary-precision) integer whose most significant set bit is in position 1023". I probably should have phrased tha…

>For some reason, ...

Ah, that clears it up, thank you!

Post reply on HN