
Failures in NIST’s ECC standards [pdf] - lisper
https://cr.yp.to/newelliptic/nistecc-20160106.pdf
======
byuu
And yet unfortunately, LibreSSL still doesn't support any safe curves (
[https://safecurves.cr.yp.to](https://safecurves.cr.yp.to) ) like Curve25519.
Nor the ability to choose between multiple curves for the 99% of browsers that
only support the NIST curves (only the most recent Firefox nightlies and
Chrome support it.) The former landed in OpenSSL 1.1.0, and the latter in
1.0.2, whereas LibreSSL is a fork of 1.0.1. And after Dual EC DRBG, it is
negligent to trust more curves that the NSA has tampered with.

The curve has been out for a long time now, and it really doesn't take much
code to do this. Here's a recent implementation of it that I wrote, which runs
in constant time and is based in part off curve25519-donna-c64 and with some
help from MerryMage:

[http://hastebin.com/raw/lutiloyaxa](http://hastebin.com/raw/lutiloyaxa)

As you can see, most of the work is just simulating a 256-bit type
efficiently. But they should already have the field element types in their
signify code (which uses Ed25519), so they'd only have to write the first 86
lines of that code.

At this point, I've pretty much given up hope of being able to use the even
nicer Curve448 within the next five years with TLS. I'm unaware of any TLS
libraries or browsers that support it.

~~~
dogma1138
OpenSSL supports ECC X25519 since august this year.

Apple uses 25519 for iCloud encryption as well as encrypting AirPlay and
wireless communication with various accessories.

X25519 Is also supported in Chrome
[https://www.chromestatus.com/feature/5682529109540864](https://www.chromestatus.com/feature/5682529109540864)

~~~
byuu
> OpenSSL supports ECC X25519 since august this year.

"The former landed in OpenSSL 1.1.0"

> X25519 Is also supported in Chrome

"only the most recent Firefox nightlies and Chrome support it"

> Apple uses 25519 for iCloud encryption as well as encrypting AirPlay and
> wireless communication with various accessories.

I was referring to its use in HTTPS/TLS, but that's good to hear! :D Hopefully
they'll add it to Safari soon.

~~~
dogma1138
Wasn't contradicting you, just adding a bit of info. Does firefox actually
supports X25519 now? I haven't seen it in the builds (it's also not on the
reference list i use). I know Edge is going to support it by the end of the
year, no clue on Safari yet.

But anyhow if you want to have a full list of software that supports
Curve25519/X25519(DH) as well as other open crypto standards IANIX has an upto
date list [https://ianix.com/index.html](https://ianix.com/index.html)

~~~
byuu
Oh okay, in that case my apologies for the misunderstanding ;)

Firefox is said to support it in the nightly releases, but not yet in the
official releases. This is the last time I checked about a month ago (I no
longer use Firefox.)

------
bsder
I can also tell you that cryptography libraries are complete piles of failure
if you want to run on an embedded device.

C++ is a non-starter. Non-open licenses are non-starters since nobody will
review the library. GPL libraries are radioactive legally. Opinionated
libraries are wonderful--unless you have to interoperate (see NaCl and
libsodium). Dynamic allocation is death in embedded (looking at you libgcrypt
and your stupid s-expressions garbage).

And, if you want some hardware acceleration, your choices are ...

Zip. Nada. Zilch.

And then everybody wonders why security in IoT sucks.

(Botan is probably the least bad. It's C++, but they went out of their way to
provide a C API and even have Python bindings in the source(!). Unfortunately,
it's lots of atomized C++ classes and inheritance to trace through for what
looks like not a lot of gain. It's not immediately clear how to inject
hardware acceleration either.)

~~~
JoachimS
Fellow embedded engineer here.

I think the ARM MbedTLS (former PolarSSL) isn't that shabby. WolfSSL is pretty
ok too. And then there are things like TweetNaCl by Schwabe et al that works
really well in embedded space.

HW acceleration for ECC is very rare in MCUs, but quite a few sports AES with
a couple of modes, typically CTR and CBC. Bigger ones (based on Cortex-M4) may
even support AEAD modes like GCM.

~~~
bsder
> And then there are things like TweetNaCl by Schwabe et al that works really
> well in embedded space.

I stumbled on TweetNaCl by accident. It's _amazingly_ useful.

But, it's like it's being kept hidden. It's not at all easy to find when you
are digging through crypto libraries looking for stuff. That's so terribly
unfortunate because there are so many other libraries that are so amazingly
difficult to port and use.

------
koverstreet
djb's papers always make for good reading. I wish more papers were written as
straightforwardly as his.

------
tptacek
There's a previous discussion about this somewhere (it's from earlier this
year, written for a NIST summit on next-generation elliptic curve standards).

I can offer a quick cheat sheet:

* The NIST ECC problem everyone is aware of is that the seeds used to generate the curves have totally unknown provenance. Pretty much everyone agrees that's a problem; it's not really a live issue. Whatever the next curve standard is, it won't have this problem.

* NIST's ECC standards included an ECC-based PKRNG, which is a CSPRNG based around a public key operation rather than a hash or cipher. Pretty much everyone agrees that the only practical reason to use a PKRNG is to allow the holder of the secret private key to extract the state from people's RNGs and predict their random numbers; it's a form of key escrow. It was very bad that NIST standardized a PKRNG.

The meat of the paper is about Curve25519 and Ed25519, Bernstein's competing
curves. These constructions are basically responses to the flaws of the NIST
standards:

* The NIST curves are misuse-prone. When receiving ECC parameters from your counterparty, there's a validation routine you must perform precisely, or else an attacker can trick you into performing a computation using your secret on an unexpected and insecure curve. This attack is very simple to perform and pretty spectacular: you can use it to remotely suck the private key out of a remote server. There are some variants of the attack (oversimplifying: there's the generic problem of not doing validation, and the more sophisticated problem of how you send coordinates, and whether protocol details like this can allow attackers to force attacks onto related-but-insecure "twist" curves).

* The NIST curves are difficult to implement without timing leaks. That's what the Montgomery Ladder stuff is about: it's an algorithm that's simultaneously constant-time, efficient, and _simple_. NIST's curves are difficult to work with in these terms, and Bernstein's aren't.

* The NIST curves have a naive design with respect to modern computer architecture, and so it's easier to generate fast curve software with other curves (like Curve25519; the 25519 refers to the structure of the prime field it works in, and that prime field was chosen to be efficient to compute on in software).

* NIST originated DSA and ECDSA, the two most popular public key signature protocols. DSA/ECDSA sucks. A lot. They rely on random nonces and blow up _spectacularly_ if those nonces are biased; it's become a bit of a sport in ECC research to get practical attacks out of extremely small nonce biases (a problem that's easy to have).

* Modern signature schemes have a bunch of nice features that DSA signatures don't; they're bulletproofed internally against attacks that could isolate weaknesses in specific parameters (the hash used, the nonce and the key), the math is tweaked so that things like modular divisions that are hard to do in constant time are replaced with multiplications, and the system is hardened to make it difficult to launch batch attacks (attacks where it costs only marginally more to attack 1000 signatures than to just attack 1). The next NIST signature standard should be like those nice signature systems, not DSA, which, again, sucks.

The paper is worth reading! I think it's a little easier to read with the
roadmap. :)

~~~
divbit
Interesting reading w'r't' DSA from this past week:
[http://eprint.iacr.org/2016/961](http://eprint.iacr.org/2016/961)

~~~
jlgaddis
I think that paper is "submission worthy" itself.

------
based2
[https://www.reddit.com/r/crypto/comments/3zu3ls/failures_in_...](https://www.reddit.com/r/crypto/comments/3zu3ls/failures_in_nists_ecc_standards/)

