
Keylength – Cryptographic Key Length Recommendation - jonbaer
https://www.keylength.com/
======
CiPHPerCoder
You probably shouldn't even _entertain the notion_ of RSA or finite field
Diffie Hellman anymore. In general...

Public key encryption: Use X25519 (RFC 7748) then 256-bit symmetric-key
encryption in an AEAD mode. (When in doubt, ChaCha20-Poly1305 is a great
choice with ephemeral keys.)

Public key signatures: Use Ed25519 (RFC 7748) or deterministic ECDSA (RFC
6979) over a 256-bit curve.

And obviously, the key sizes on that page have _no_ applicability to post-
quantum cryptography key sizes.

~~~
geofft
A lot of us have to interoperate with systems that don't easily support
Curve25519 or ChaCha20-Poly1305, let alone post-quantum algorithms. As RSA and
finite-field DH aren't _broken_ , I'd rather use a well-tested implementation
of one of those with sufficient key length than try to backport a newer
algorithm. (For new protocols and new code, sure.)

What I find this page useful for is pointing out lower bounds on security
levels. If you're building a system that, eventually, outputs a file format
with 256-bit hashes of files, there isn't a point in using any stronger crypto
than a 128-bit security level to sign and transmit the hashes. If you want to
make the system more secure, first figure out how to make the hashes longer.

~~~
CiPHPerCoder
> As RSA and finite-field DH aren't _broken_

No, but their implementations often are. For a recent example (Zend Framework,
just at the end of 2015):
[http://framework.zend.com/security/advisory/ZF2015-10](http://framework.zend.com/security/advisory/ZF2015-10)

More famously: [http://www.cryptofails.com/post/70059600123/saltstack-
rsa-e-...](http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1)

RSA has more knobs to turn than EdDSA, and leads greater room for implementor
error.

~~~
Someone1234
I'm confused. Above you're arguing for the use of newer schemes which are
available with newer code which has not been as time-tested, here you're
suggesting that the reason to avoid older well-tested schemes is poor
implementation?

Aren't these two points contradictory. Unless you have a reason why the new
scheme's implementation is more likely to be flawless than older
implementations which may have received bug fixes or reviews. Seems to me that
implementation bugs are a good reason to stick to older heavily used code,
rather than jumping to the latest new thing.

~~~
tptacek
You're confused because you're unfamiliar with the concepts being discussed.
That's not the same thing as being confused because the parent comment's
argument is flawed.

RSA is dangerous for a bunch of reasons:

* It has selectable key sizes and performance parameters that beg people to deploy it insecurely. That's the concept you're probably roughly familiar with.

* It is subject to a far greater diversity of implementation faults (for instance: because of its padding requirements, or because of its relatively complicated key generation process) than alternative algorithms.

* It offers one primitive operation you actually want (signatures) along with one you almost never want (encryption), which results in cryptosystems like classical TLS or, worse, every system that ever directly encrypted a credit card number with RSA. Alternative algorithms don't offer this foot-gun.

* The underlying mathematics of RSA are weakening(/improving) faster than those of elliptic curve; we could lose RSA entirely within our lifetimes even if quantum doesn't come to pass.

You don't have to take my word for it. Survey modern cryptosystems. Note which
ones depend on curves and which depend on RSA, and then investigate the
reputations of each of those systems.

~~~
Someone1234
> You're confused because you're unfamiliar with the concepts being discussed.
> That's not the same thing as being confused because the parent comment's
> argument is flawed.

That's very unnecessarily condescending. You then go on to criticise RSA,
which is fine, but fails to address the point I made which was that they
criticised RSA's implementation, not its inherent design flaws, while
promoting a newer scheme with a less time-tested implementation.

This is verbatim what I was responding to:

> As RSA and finite-field DH aren't broken

>> No, but their implementations often are.

PS - I strongly suspect your tone is a result of another thread of discussion
we had in this topic[0]. I'd suggest you make snide remarks there rather than
carrying it over into this thread.

[0]
[https://news.ycombinator.com/item?id=11909436](https://news.ycombinator.com/item?id=11909436)

~~~
CiPHPerCoder
Let me clarify a bit then: My criticisms of RSA stem from studying how people
implement it in cryptography libraries.

More people implement PKCS1v1.5 padding than implement RSAES-OAEP in their
application-layer crypto, and that's a problem.

Conversely, most of the applications I've analyzed that wanted ECDSA/ECDH used
OpenSSL or libsodium.

Guess which ones were broken with chosen-ciphertext attacks.

If you want a theoretical concern: Index calculus attacks.

If you want a practical concern: Look at the traps that cause implementations
to be comically insecure.

------
tptacek
Key size does not matter. Algorithm selection and mode does.

~~~
dsacco
I agree with this, but I think it could be phrased in a more nuanced way. I
would state it thusly:

 _" Key size is a red herring. People fetishize key size because it's the most
identifiable number and our monkey brains just want to make that number as
large as possible. But key size is a not a dial you can tune in any context,
and good cryptography depends on algorithms, not key sizes. A well-designed
algorithm explicitly defines the key sizes you can select because it limits
how much users can shoot themselves in the foot. The number of bits is not
important, it's the way in which the algorithm creates a ciphertext using that
number. Theoretically, a proven secure algorithm using an encryption function
with a single bit key size would be perfectly fine to use."_

I think that would be interpreted more charitably :). Then again, that's
typing a lot more.

Hey for anyone reading this, this is basically why companies that state they
use "bank-grade" or "128 bit" encryption on their cool landing pages aren't
really saying anything.

~~~
MichaelGG
>Theoretically, a proven secure algorithm using an encryption function with a
single bit key size would be perfectly fine to use

Can you elaborate? With a single bit key you can simply try both keys...
right?

~~~
dettervt
I believe what was meant was a single key size measured in bits, not just a 0
or 1.

