ucc-entry.txt

A MODEST PROPOSAL FOR A NEW STANDARD ELLIPTIC CURVE
Submitted to the 2014 Underhanded Crypto Contest
by Daniel Fox Franke <dfoxfranke@gmail.com>

In a recent CFRG discussion, Microsoft has recently proposed a new
elliptic curve for standardization, different but similar to
Ed25519. Although this move has drawn some criticism, I believe that
the availability of a wider variety of standard curves will give
end-users greater flexibility to select one which satisfies their
particular security requirements. Furthermore, in the wake of the
Dual-EC-DRBG controversy, concerns have been raised about the
integrity of the widely-used NIST curves and the possibility of NSA
influence on their design. The inclusion of a curve with provenance
from Microsoft expands the list of independent parties contributing to
the set of standard curves, thus improving the probability that at
least one of them is trustworthy.

Given that I have never held any affiliation with Microsoft, NIST, the
NSA, Brainpool, Certicom, ANSI, ANSSI, the IEEE, or, to my knowledge,
any other party that has standardized a curve, I am well-positioned to
further contribute to the variety of available curves by proposing the
following.

Curve UCC-256 is defined over the prime field of integers modulo

p = 538941700537609333224396980346477299679432469412860732384109784314799534611323

The curve is defined by the equation

y^2 = x^3 + ax + b,

where

a = 214976745112404465015297496798687605623521300415148529615182938084753061115831
b = 215976636950136578806066322365193129370607445998474801845951230820030982330328

Its order is
28563910128493294660893039958363296883009920878881618816357818568684375334400119,
and the group generated by the following base point has a cofactor of 1:

g_x = 261279312021209381745206766263129413639182469479255551068877884275110089662530
g_y = 246142927835339659168887345529310746090640625359701912959529791738864124194651

It is my aim to set a new high-water mark for transparency in
parameter generation. To that end, all of these values are
nothing-up-my-sleeve numbers which I generated by singing the Bohemian
Rhapsody backward with my dog barking in the background, digitizing
the audio as an MP3 at a bitrate of 192kbit/s, and taking every 17th
byte of the result. Their integrity can easily be verified by
repeating this procedure.

Like the NIST curves, but unlike Curve25519/Ed25519, UCC-256 is a
Weierstrass curve, making it straigtforward to incorporate in
protocols which expect curves to be in this format. I have included a
sample patch which adds UCC-256 support to OpenSSL 1.0.1j.