Hacker News Reader

Comment by drdaeman | Hacker News Reader

> RSA is obsolete. Stop using it.

The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?).

Neither Curve25519 nor Curve448 - which are said to be safe - are usable with X.509 and TLS, yet. Still waiting for that RFC to get past the draft status.

So, what should we do?

View on HN

> The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe.

I don't believe this is accurate. It is true that there are complaints about the curves' design in parameter transparency and their difficulty to implement them securely. But I don't think people are actually suggesting the curves are not safe to use conceptually.

P-256 facilitated ECDSA should be good to use until the new curves are adopted (which will take a while) as long as you're not writing implementations yourself. It is true that the new curves will be a better alternative once they are available given that they are designed for transparency and ease of implementation.

You have two choices then:

    - Use RSA until 25519/448 land in TLS
    - Switch to ECDSA in the interim

Personally, I would switch even though ECDSA isn't great.

The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible.

You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy.

EDIT: I use secp384r1 for signing random_compat, so if anyone gets bit by this recommendation, I will too: https://github.com/paragonie/random_compat/blob/master/dist/...

The NIST curves also have constants which may or may not be manipulated.

Bruce Schneier recommends against using them.

I would recommend against using them if your adversary is the NSA and your threat model comes wrapped in tin foil (and if I didn't, I'd get ignored anyway).

If so, use NaCl/libsodium at the application layer and don't rely on ECDSA alone.

If your threat model is "criminals", ECDSA is less insane than RSA (provided, once again, you're not implementing it yourself, you're relying on developed by a team of cryptographers and security engineers).

Threat model wrapped in tin foil? I don't understand what you mean, are you suggesting paranoia?

My threat model includes NSA dragnets but not being specifically targeted by the NSA.

In that case, active attacks against Weierstrass field arithmetic isn't part of your threat model and ECDSA/ECDH over the NIST curves is fine.

So this is something that can't be done en masse? Okay, thanks.

>> Threat model wrapped in tin foil? I don't understand what you mean, are you suggesting paranoia?

That term likely means one of two things: guarding against a particularly capable attacker or paranoia for others

NSA dragnets won't decrypt things using dodgy curves for signatures (ECDSA), only things using dodgy curves for key exchange (ECDH).

Even Bernstein doesn't argue that the NIST curve seeds are actually backdoors. Schneier isn't a curve researcher; in fact, he's more like an anti-curve pundit. I'm not sure his opinion is all that powerful.

Regardless, I'm not suggesting new cryptosystems should use the NIST P-curves. They shouldn't; those curves are just as tricky to use as RSA.

What about the NSA "freaking out"[1] about ECC in general?

[1]: http://blog.cryptographyengineering.com/2015/10/a-riddle-wra...

Rodents of unusual size? I don't think they exist.

Your vote of confidence is overwhelming. ;)

Use Curve25519.

drdaeman says that Curve25519 isn't usable with X.509 and TLS. Your reply is "Use Curve25519". What are you saying? That drdaeman is wrong, and Curve25519 can be used with TLS? Or are you saying, "don't use TLS"? Or... what?

The spec for Ed25519 signatures in TLS is not yet ready: https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-02

X25519 for key exchange in TLS is ready and is in openssl master (and in boringSSL). I don't know the status of NSS support, or plans for SChannel and CoreCrypto support.

X25519 key exchange and Ed25519 signatures have been deployed in nacl, libsodium, ssh, etc. for a while.

EDIT: NSS ticket for X25519 Key Exchange: https://bugzilla.mozilla.org/show_bug.cgi?id=957105

Frankly I don't do security critical things on TLS anymore. I'm tired of having to wait in limbo for months to fix known vulnerabilities.

What do you use instead? SSH? IPSec?

Go to datacenter. Open cage. Plug in keyboard. Oldschool.

Are you shielding the keyboard from EM leakage? I don't open a cage, I get in one and do my work in there... No more EM eavesdropping.

Unless there is an enemy antenna with you inside the cage. A real security pro uses a pneumatic keyboard.

No magnetized needle and a steady hand?

Other protocols are probably just as broken, we just haven't found the vulnerabilities yet. Few protocols (if any) get as much scrutiny as SSL/TLS.

This seems like what a sensible person would do.

On the other hand, placing evergreen confidence in "TLS", believing that it is "good enough" or concluding "it's all we've got" are lines of thinking that not make sense to me. The vulnerabilities just keep coming, one after another.

High speed crypto not part of TLS that, as another commenter put it, is "considered safe". Does it exist?

Useful software that is written from the start with such care that it does not need to be continously patched ad inifitum. Nonexistant? (No need to answer. I know the truth.)

Getting something added to TLS seems difficult enough, but getting something removed seems impossible. Like all bad software, TLS has numerous "features" I do not need and will never use. OpenSSL is like a museum of cryptography, preserving the obsolete for posterity.

Long live TLS. May it forever waste my time and energy.

Reply on news.ycombinator.com