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

61–70 of 125 posts

Re: Seriously, Stop Using RSA (2019)

#61

Post by nullc »

dhzhzjsbevs wrote: post #58
duskwuff wrote: post #55

Earlier quoted context omitted.

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

Starting to sound a lot like your description of RSA, just more positive about it.

key[31]=(key[31]&63)|64;key[0]&=248;

is radically simpler and not remotely comparable to the requirements for RSA key generation. Moreover, RSA key generation is massively slow-- enough to be irritating for users even on fast computers so there is a lot of incentive to 'optimize' key generation and introduce complexity that results in bugs.

(do not use, I just implemented what the GP poster said, didn't check if it what he said was correct, but it sounds right)

Re: Seriously, Stop Using RSA (2019)

#62

Post by aborsy »

There is a menu of ECC algorithms out there. We have seen some of them were backdoored, and there are probably more of those.

If you aren’t sure which ones are safe, it might be better to use RSA from a standard source (OpenSSL, PGP, SSH etc).

Users don’t implement algorithms, and don’t cares if they are hard to program.

Re: Seriously, Stop Using RSA (2019)

#63

Post by hinkley »

aborsy wrote: post #62

There is a menu of ECC algorithms out there. We have seen some of them were backdoored, and there are probably more of those. If you aren’t sure which ones are safe, it might be better to use RSA from a standard source (OpenSSL, PGP, SSH etc). Users don’t implement algorithms, and don’t cares if they are hard to program.

Let this be a lesson to whoever comes next: cute and distinct names for your cryptographic algorithm make it easy to distance yourself from people who create similar algorithms that turn out not to be secure.

RSA is fundamentally a trick of modular arithmetic, but it's not called that, so if someone else fucks up their modular arithmetic, it doesn't immediately bring shame and doubt upon RSA.

Meanwhile the ECC community is using an algorithm that is basically 'Curve' plus a five digit number. If this name isn't already being openly mocked, it will be at some point in the future. Normal people don't have lists of 'good' and 'bad' numbers in their heads. If Curve#### is found to be bad, then they'll think Curve##### is the one everyone is talking about.

Re: Seriously, Stop Using RSA (2019)

#64

Post by duskwuff »

nullc wrote: post #61
dhzhzjsbevs wrote: post #58

Earlier quoted context omitted.

Starting to sound a lot like your description of RSA, just more positive about it.

key[31]=(key[31]&63)|64;key[0]&=248; is radically simpler and not remotely comparable to the requirements for RSA key generation. Moreover, RSA key generation is massively slow-- enough to be irritating for users even on fast computers so there is a lot of incentive to 'optimize' key generation and introduce complexity that results in bugs. (do not use, I just implemented what the GP poster said, didn't check if it w…

> Moreover, RSA key generation is massively slow--

Not only is it extremely slow, but it's also non-deterministically slow -- there's no constant-time way to randomly generate an RSA key, because searching for suitable primes is a "guess-and-check" process.

ECC key generation, on the other hand, is so fast that it's perfectly feasible to use it as part of the session negotiation process (e.g. in ECDHE).

Re: Seriously, Stop Using RSA (2019)

#65

Post by duskwuff »

dhzhzjsbevs wrote: post #58
duskwuff wrote: post #55

Earlier quoted context omitted.

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

Starting to sound a lot like your description of RSA, just more positive about it.

Explaining all of the ways an RSA key can be weak, and what you have to do to avoid generating one, would take a lot longer.

Re: Seriously, Stop Using RSA (2019)

#66

Post by YATA0 »

prophesi wrote: post #59
YATA0 wrote: post #47

Earlier quoted context omitted.

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

Quoted post unavailable.

>Then using HashiCorp Vault isn't the silver bullet

Except it practically is.

That's like saying Linux isn't a silver bullet because ls doesn't make filesystems... You wouldn't use Vault to create SSH keys, nor should it. You wouldn't use ls to make filesystems, nor should it.

Re: Seriously, Stop Using RSA (2019)

#67

Post by thaumasiotes »

nullc wrote: post #61
dhzhzjsbevs wrote: post #58

Earlier quoted context omitted.

Starting to sound a lot like your description of RSA, just more positive about it.

key[31]=(key[31]&63)|64;key[0]&=248; is radically simpler and not remotely comparable to the requirements for RSA key generation. Moreover, RSA key generation is massively slow-- enough to be irritating for users even on fast computers so there is a lot of incentive to 'optimize' key generation and introduce complexity that results in bugs. (do not use, I just implemented what the GP poster said, didn't check if it w…

> (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 second-highest bit twice? Why not just write `(key[31]&127)|64`?

(And then of course, why not use the hexadecimal form of your bitfield constants so people can tell what's going on? No need to count bits that way.)

Re: Seriously, Stop Using RSA (2019)

#68

Post by thaumasiotes »

olliej wrote: post #52
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,…

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

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

I don't think the argument is that "we've had RSA since the 70s". I think it's "we've had RSA since the 70s and we still can't break it".

Re: Seriously, Stop Using RSA (2019)

#69

Post by stouset »

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.

Re: Seriously, Stop Using RSA (2019)

#70

Post by tialaramex »

duskwuff wrote: post #65
dhzhzjsbevs wrote: post #58

Earlier quoted context omitted.

Starting to sound a lot like your description of RSA, just more positive about it.

Explaining all of the ways an RSA key can be weak, and what you have to do to avoid generating one, would take a lot longer.

This is not really fair. The correct way to mint RSA keys is actually pretty simple, 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 tests you've advocated make sense if somebody else picked the keys and you're worried whether they did a good job, some of these tests are mandatory for a Web PKI Certificate Authority checking RSA public keys for example (the CA only has your public key so it can't check everything), but if you are picking the keys you really can just use the naive approach. The odds of "accidentally" getting two factors that are unduly close or very smooth are negligible.

Post reply on HN