Hacker News Reader

Comment by jchook | Hacker News Reader

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.

View on HN

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

>set and clear a couple bits

What bits?

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.

It's two bitwise operations

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)

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

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

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.

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.

> 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 prime, and if it's not throw it out and pick a new, unrelated, 1024-bit integer, and repeat until you have two to multiply together. This will, probably, produce a secure RSA key. Definitely upwards of half of the time, assuming your primality test has sufficiently low false positive rate.

It's just ('just') painfully slow, so people almostly always optimize it. There are some optimizations that provably don't change the distribution of primes (the most obvious being marking the least significant bit so the number is never even), but history has shown that any optimization that doesn't exactly and exactingly preserve the distribution almost always turns out to introduce exploitable vulnerabilities.

Of course, even if you do it wrong it's still slower than barely-optimized ECC, and even if you do it right it still has vastly less security than a ECC key a quarter of it's size.

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

>For some reason, ...

Ah, that clears it up, thank you!

“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 :(

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

The point is that we have, over and over again. We’ve just recently had headlines about poorly chosen p and q leading to keys being broken. There have been issues with p and q being too small, too similar, etc. Then there are people not padding correctly.

RSA sounds easy, but in reality it isn’t. It is super easy to make minor mistakes that make your scheme trivially breakable.

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

Actually, even that is wrong; you can't[0] securely pad a message; you have to use P^(K:=rand(N)), then use K (or preferably H(K)) as a symmetric encryption key to encrypt the actual message.

0: outside of a handful of special cases, of which `rand(N)` is the only example I'm reasonably confident in

Another downside is that ciphertext is also quite bulky.

ECDSA is a lot computationally cheaper for the same strength. Switching from RSA to ECDSA TLS certs can have a significant impact on the CPU usage for, say a reverse proxy. (By extension, costs less in terms of money and environmental impact).

That being said, I do think that global monoculture and putting all eggs in one basket as a society is a bad idea. If you're willing to take the cost and prefer to use something you understand - by all means do so, as long as you're aware of the tradeoffs you're making.

Of course it is a bad idea. See OpenSSL.

Could you elaborate on how you think that is relevant to what I wrote?

GP is almost certainly agreeing with your statement:

> global monoculture and putting all eggs in one basket as a society is a bad idea

Ah, you're probably right, ambiguous violent agreement (:

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

Then I'm sure you can explain where the number c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 came from.

http://safecurves.cr.yp.to/rigid.html

https://credelius.com/credelius/?p=97

With Curve25519, by contrast, DJB explains exactly what constraints were imposed (with very solid justifications for each of them) and then proves that Curve25519 is the unique solution to these constraints which minimizes the remaining free coefficient (which maximizes efficiency). NIST should appoint him to be their Czar or something.

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/]."

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

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.

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.

Reply on news.ycombinator.com