[cryptography] Curve25519 OID

Billy Brumley bbrumley at gmail.com
Tue Oct 8 12:48:59 EDT 2013

> I would appreciate expansion on all these horror scenarios.
> Most of the desirable characteristics of curve25519 are things that make it different from NIST curves, for example montgomery coordinates protect you against point compression patents, since you don't calculate y, therefore cannot violate someone's patent for calculating y, not to mention that point compression, montgomery coordinate style, has prior art going a long way back.
> Further, we should automatically distrust everything touched by NIST, because we cannot invest the time, energy and thought to check out everything they have touched.

Here is a non-exhaustive list of features curve25519 as a function
(and sometimes even a curve) gives you.

1. Avoiding point compression. (You mentioned this already.)
2. Protection against invalid curve attacks.
3. Protection against small subgroup attacks.
4. Easy private key generation. (32 random bytes and clear some bits
vs random integer from 1 to n where n=generator order.)

In reality, most libraries (e.g., OpenSSL) will already handle 1-4
above in one way or another because they're setup to handle generic
(Weierstrass form) curves.

The horror scenarios in my head are more about integration. Here are
some examples.

Scenario #1
Weierstrass form of curve25519 gets standardized. Its parameters get
dumped in as a named curve into a library (e.g., OpenSSL). The
implementation handles it as a generic curve. Its scalar
multiplication routine is like any other curve--some windowed NAF or
sliding window with execution time dependent on secrets--not
side-channel secure.

Scenario #2
Weierstrass form of curve25519 gets standardized. A secure
implementation also gets integrated into a library (e.g., scrape some
code from NaCl to OpenSSL). So the implementation of the curve
arithmetic is great. Then it's used for digital signatures like ECDSA
and the "mod n" arithmetic has execution time dependent on secrets.

So it depends on where your concerns fall--cooked curves or poor
implementations (that put secrets at risk)? Mine are of the latter
variety--we have proof of them and I've personally carried them out
many times in the past.

My 2c: Standardize the Weierstrass form of curve25519. Handle
integration aspects as needed. There's some evidence to support that
this is acceptable. (E.g., E. Käsper's secure implementation of P-224
got picked up by OpenSSL and no one is barking about the other moving
parts yet.)


More information about the cryptography mailing list