Hacker News Reader

Comment by dom0 | Hacker News Reader

RSA is very difficult to implement correctly and has a great number of caveats there. Generating keys is a very complex process, which is very slow compared to (some) ECC systems.

RSA is an asymmetric system that gives you: 1.) eternal signatures 2.) encryption. But today we often don't want that anymore (eg. in instant messaging), instead we want:

- Forward secrecy, necessitating ephemeral keys and DH: but RSA keys can't be feasibly generated for each message or connection. Compared to eg. 25519-based ECC, where generating a key pair is 1.) generate 32 random bytes 2.) curve multiplication, meaning that you can generate many thousand keys/second/core.

- Authenticity, not signatures, hence again DH + MACs, not RSA signatures.

View on HN

This isn't really accurate. It is true that ECDSA key generation is faster than RSA, but particularly in the context of SSH this doesn't matter. Also, I think you may be confusing ECDH and ECDSA. ECDSA (which is what the article is recommending) is the directly analogous to RSA in the sense that it provides eternal signatures. ECDH provides for generating individual session keys, but you can do that with classic Diffie Hellman as well, it is a completely separate issue from RSA vs EC.

Also, this line doesn't make any sense: "Authenticity, not signatures, hence again DH + MACs, not RSA signatures."

You need an signature to have authenticity. The only alternative to this is pre-exchanging symmetric keys which isn't viable in the context of SSH.

You're correct, I'm not referring to SSH specifically, but speaking generally about the application of asymmetric crypto. The quote in GP, and GP's question, both seemed to indicate this broader context to me.

Even in a broader context, Symmetric keys based MACs vs signatures is a completely separate question from RSA vs EC.

(Also, obviously RSA does not do DH or a similar mechanism for establishing a shared secret. The workaround is to generate ephemeral keys and sign their public keys with RSA, then generating a shared secret from the ephemeral keys. This is what eg. TLS does in principle, but also shows that RSA still has it's uses: RSA signatures for long-term proofs of identity, ECC for forward-secure communication.)

There are also other caveats. Eg. EC keys tend to be tiny, just like symmetric keys, so one can much more easily distribute them through eg. QR codes, or even read them out loud. RSA keys, not so much.

If ECC fits the application well then using eg. Curve25519-based crypto over RSA or other EC is pretty much a no-brainer: it's, by a large margin, the asymmetric crypto systems with the fewest caveats both in implementation and application, and it's also very fast for any operation.

RSA signatures are valuable in TLS because the installed base uses RSA, not because you need RSA to solve the problem RSA solves in TLS. There are better ECC constructions for signing and verifying.

Reply on news.ycombinator.com