[tahoe-dev] elliptic curves with verifiably pseudorandom parameters Re: #466 state-of-the-patch

[Zooko O'Whielacronx]

(Part two in an on-going series of comments on this ticket, at a rate
of approximately one per night, apparently. :-))

Here is my pitch for why we should consider using Brainpool curves
instead of NIST curves. The key technical difference is that the
Brainpool parameters were generated in a verifiably pseudorandom way,
so they are unlikely to have some sort of backdoor built into the
choice of parameters:

http://tools.ietf.org/html/rfc5639

An example of a potential backdoor being built into the choice of
elliptic curve parameters was shown by Shumow and Ferguson in the
"Dual_EC_DRBG" PRNG. Schneier wrote up a good explanation:

http://www.schneier.com/essay-198.html

I don't know whether any such backdoor is even possible in ECDSA. What
I do know is that the verifiably pseudorandom parameters of the
Brainpool curves eliminate one such potential backdoor.

I really don't like "popularity contests" in general, but when
choosing a crypto primitive, if there is a legitimate constituency
that distrusts an option then that is a good reason to use a different
option. I don't want some potential future users to distrust
Tahoe-LAFS because it relies on the NIST curves (even if the majority
of potential future users trust the NIST curves).

What we're talking about here is basically geo-politics, I guess.
People who trust NIST and NSA to be honest and/or to be on their side
are fine with the NIST curves, but those people should also be fine
with the Brainpool curves. The first significant user base to go with
the Brainpool curves is the German federal government, who sponsored
the development of the Brainpool curves and are now deploying them.

Note that you do not have to trust the German federal government to be
satisfied using the Brainpool curves! This is because they are
generated with a specific PRNG using SHA-1, seeded with π. See
http://tools.ietf.org/html/rfc5639 .

Note this is a similar "marketing" issue to why I want Tahoe-LAFS to
continue using AES in addition to another stream cipher even though I
personally think that alternatives such as XSalsa20 are safer than
AES. For people out there who disagree with me and think that AES is
safer, I don't want to reduce their trust in Tahoe-LAFS by using
XSalsa20 alone.

One practical matter is that Brainpool curves are not yet implemented
in OpenSSL, which python-ecdsa uses for interop testing. If anyone out
there knows how to push these patches along in the OpenSSL process,
please do so:

http://rt.openssl.org/Ticket/Display.html?id=2239&user=guest&pass=guest
http://rt.openssl.org/Ticket/Display.html?id=2359&user=guest&pass=guest

I suspect that a good way to push these patches along would be to
provide a patch that adds some Known-Answer Tests.

Regards,

Zooko