
Million Dollar Curve - aburan28
http://cryptoexperts.github.io/million-dollar-curve/
======
tptacek
The thesis of this paper seems to be that there aren't many alternatives to
25519. But anybody who watched the fiasco of the IRTF trying to standardize a
recommendation on 25519 knows that's not true. Browser vendors were sold on
DJB's curve and asked IETF to add it to TLS; given that simple charter, people
came out of the freaking woodwork with alternatives.

The "randomness derived from lotteries" property seems like a gimmick.
Generating plausible random seeds isn't the hard problem with generating new
curves. Rather, the problem is coming up with curves that are performant on
common hardware without any patent-encumbered techniques.

It's also not clear to me how the $1MM curve is a meaningful alternative to
25519. Almost the entire paper is given to considering how to generate random
parameters. Having accomplished that task, the paper simply generates a random
Edwards curve, using their lottery generator to find a random prime, d, and
base point, filtered against the SafeCurve requirements. So they end up with
(in effect) a randomized version of Bernstein's curve. If 25519 somehow falls,
why wouldn't this curve fall with it?

Compare this paper to those of 25519:

[https://cr.yp.to/ecdh/curve25519-20060209.pdf](https://cr.yp.to/ecdh/curve25519-20060209.pdf)

... or to FourQ:

[https://eprint.iacr.org/2015/565.pdf](https://eprint.iacr.org/2015/565.pdf)

Also: the swipe at Brainpool seems disingenuous. Zero is the number of people
who believe that Brainpool's mathematical constants were arranged specifically
to create a backdoor. The point of BADA55 is that Brainpool's use of
mathematical constants as seeds isn't dispositive, and that the performance-
targeting parameters of 25519 are equally credible.

~~~
fryguy
I don't think that's the thesis. I think the thesis is that there could be a
"BADA55 construction" even in Curve25519. Even though all of the individual
pieces are justifiable, for instance the 2^255-19 is justifiable because it's
the smallest number. They knew the entire curve before trying to make it
popular. Also, they could have used 2^255+95 because it's the smallest
_larger_ than 2^255 with some justification that it needed to be larger than
2^255. With enough arbitrary decisions a "one-in-a-million" vulnerability is
possible. The premise of this curve is that there are no arbitrary decisions,
since you commit to supporting the curve before even knowing what it is.

I think the analogy is someone shuffling a deck of cards, and taking a peek at
the first card. Then betting someone $20 that it's the ace of spades. The
process is justifiable, because you don't have any control of what the top
card happens to be. It's just that you know what card it is and wouldn't make
the bet if you didn't know it was already an ace of spades. Similarly,
Curve25519 might have been constructed and happened to have the "one-in-a-
million" vulnerability. How many other "Curve25519s" are there that we didn't
hear about. Imagine that instead, the procedure was shuffle the cards _after_
you commit to the bet.

I really doubt there's anything wrong with 25519. I feel like if anything, if
djb et al knew about some vulnerability in curves that 25519 happened to have
before releasing it, they would have put the weakness as one of the failing
criteria to pick a new set of parameters.

~~~
tptacek
I'm pretty sure the authors aren't suggesting that Curve25519 has been
tampered with, because the FAQ for this paper suggests (a) that they continue
to recommend Curve25519, and (b) that they are proposing this curve because
they're concerned that there aren't any good alternatives to Curve25519 with
trustworthy seeds.

Curve25519 follows roughly the same generation procedure as Microsoft's NUMS:
it uses minimal parameters that satisfy a performance/security goal. NUMS
starts from a security level, selects the smallest prime that satisfies that
level, and then selects the smallest Edwards 'd' that passes security
criteria. Curve25519 selects a prime of sufficient security as close as
possible to a power of 2 (making it sparse and thus fast to do math on in
software), and then selects a minimal Montgomery A given security criteria.

$1MM and 25519 represent two different schools of thought about how to
generate curves. $1MM says, generate random unstructured parameters, and come
up with a randomness procedure that is difficult to impeach. 25519 says
generate minimal parameters that achieve particular performance goals. Both
schools of thought address the concern that the curve generation procedure
might be untrustworthy, but in different ways: the former by somehow proving
randomness, the latter by removing degrees of freedom.

25519's school of thought has pretty much won the Internet.

~~~
sarciszewski
I really appreciate the level-headed discussion in this thread so far,
especially the comment I'm replying to.

It's a stark contrast to the CFRG mailing list. (At least, so far, no one has
tried to derail discussion here with "hey check out my custom cipher it's
soooo secure but you need to compress the data before encrypting it or else
you can observe a repeated structure out of it".)

I like 25519's school of thought. If you use the smallest possible value for a
given performance/security goal, there's less room for conspiracy theory
(provided the person making the theory understands what's even going on).

------
FullyFunctional
"Curve25519 was designed to be as fast as possible, with no security
compromise. This is both a strength and a potential weakness:

    
    
        a strength because it gives a valid argument that no trapdoor was introduced in the design,
        a potential weakness because Curve25519 uses a very specific prime field. As of now, no attack exploiting this specificity is known.
    

For applications where speed is paramount, Curve25519 is probably the best
option. But for most applications, where losing a little on the efficiency
side is "not a big deal", Million Dollar Curve is probably the safest choice."

Sorry, no. Many more eyeballs have been on Curve25519 and DJB reputation, both
of which gives me _more_ confidence in that than _any_ new alternative.

Secondly, the _implementation_ is as important as the design. Again,
Curve25519 have vetted implementations, something which takes time.

Finally, the notion that speed is a liability is ludicrous. The _lack_ of
speed is a major liability.

Move along, nothing to see here.

~~~
api
Also it's called "Crypto Experts," which in this particular field somehow pegs
my contrarian indicator button.

If they'd claimed to have designed a modern alternative to SSL using modern
crypto primitives that's one thing. That's hard and requires solid crypto and
coding knowledge and I wouldn't trust it without a lot of peer review, but
it's something a competent crypto-understanding developer could pull off.
Ordinary mortals can do things like combine a cipher with an authentication
algorithm correctly if they take the time to study the state of the art and
avoid previously understood pitfalls.

That's _using_ crypto as a developer. But this is _making_ crypto.

Creating a _new cryptographic primitive_ is serious deep ninja-god black magic
voodoo stuff that is beyond mere mortals... and this is coming from someone
who is very anti-elitist when it comes to most things like this. There's not a
huge pool of people I'd trust to attempt it, and even if it came from someone
like DJB I still wouldn't _use_ it until it's been in publication for at least
a few years and attacked by many Ph.D's and others. Salsa and ChaCha are some
of the newest ciphers in common use and those are now... what... a decade old?
And they've been beat up pretty badly by researchers too, so they've passed
enough of a gauntlet to be trusted with something.

So even if they did this new curve, I wouldn't use it for at least 5-10 years.

Edit:

The other thing I really don't get is why a new venture like this would start
off by trying to push an entire new curve. Unless there is some good reason
_not_ to trust C25519, there are many other more pressing concerns in the
crypto world that could be tackled. We could really use good end-user crypto
software that is solidly engineered and offers good UX. That would be of
immensely more value than yet another ECC curve with no clear benefit over
existing curves. (Other than maybe NIST but that's another matter.)

~~~
Taniwha
I think the attitude that rolling your own crypto "is serious deep ninja-god
black magic voodoo stuff that is beyond mere mortals" has a lot to do with why
we've been blythly taking NSA's deliberately broken crap.

While I know it's hard, very hard, we shouldn't be discouraging people from
making up new stuff, let a thousand flowers bloom around the NSA's walled
garden .... what we should be doing is getting rigorous about testing and
verification of new crypto be it from the NSA or the good guys

~~~
__jal
I don't think anyone wants to discourage people from learning about, playing
with, and trying to invent new crypto.

The usual problem here is that people new to crypto frequently don't treat
their whizzy new supercool algorithm as a toy that has almost certainly been
done, cracked, improved, cracked and eventually abandoned. For whatever
reason, it is entirely too easy for people new to crypto to convince
themselves they've made a really cool discovery. There's even a cliche for
this: "Anyone can create an crypto algorithm that they themselves cannot
crack."

Absolutely, learn, play, and try to make something great. But keep
perspective. You wouldn't invite your loved ones to be the first to test your
first attempt at a home-brew parachute; similarly, don't use your home-brew
crypto to protect important things.

~~~
tptacek
We should put this part of the thread to bed, because CryptoExperts is the
real deal, and it's kind of silly to debate "homebrew crypto" on a thread
about their research.

------
cperciva
_Sigh_

The issue here is that we need a trusted source of "nothing up my sleeve"
numbers:
[https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number](https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number)

This is why the RFC 3526 groups use primes derived from Pi:
[https://tools.ietf.org/html/rfc3526](https://tools.ietf.org/html/rfc3526)

I'm sure that it would be difficult to tamper with the results of lotteries
held all over the world. But it's even harder to tamper with the value of Pi.

~~~
kevhito
Sigh. This is incorrect. Pi does not give the "nothing up my sleveve"
property, because if I have a desired bit sequence in mind, I can find it in
Pi, then retroactively claim that because it comes from Pi it wasn't "up my
sleeve". Specifically, the _methodology_ of transforming the its of Pi into
the desired key was "up my sleeve".

What the authors propose here is much better. The methodology and protocol for
transforming the seed digits is agreed to ("committed") ahead of time, before
the digits are known, and only later are the numbers generated.

~~~
cyphar
> Sigh. This is incorrect. Pi does not give the "nothing up my sleeve"
> property, because if I have a desired bit sequence in mind, I can find it in
> Pi, then retroactively claim that because it comes from Pi it wasn't "up my
> sleeve". Specifically, the methodology of transforming the its of Pi into
> the desired key was "up my sleeve".

Pi has not been proven to be normal, so you can't be _completely_ sure that
you could always find any particularly long (backdoored) sequence.

~~~
Houshalter
No naturally occurring constant has ever been proven to be normal. It's a
really hard property to prove. However It's been calculated to billions of
digits and it certainly seems to be. It even passes random number tests
perfectly.

------
gherkin0
> Of course, one should not conclude that cryptographic algorithms using
> similar constants are systematically insecure (certainly, some designers are
> honest!) and we will not dispute the right to trust those algorithms.

I'm reminded a controversial aspect of the design of DES. The values of the
S-Boxes were unjustified, and some people feared they constituted a backdoor
(much like what's alleged with Dual-EC-DRGB). It turns out that in fact they
were specially chosen to _strengthen_ DES against a cryptographic attack that
the NSA was trying to keep secret.

[https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.2...](https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.27s_involvement_in_the_design)

~~~
1024core
My crypto prof in uni commented on this. (This is from memory). Apparently,
the number of rounds (16) seemed to have been chosen arbitrarily. Many years
later, when attacks on Feistel(?) ciphers (of which DES is one) became public,
it turned out that these attacks only worked up to .... 15 rounds! So the
speculation was that the NSA knew about the attack, and chose to set the round
number _just_ out of reach...

~~~
tptacek
My understanding is that NSA's changes to DES were all in the s-boxes, and
that it was the s-box changes that hardened it against differential
cryptanalysis. I think there's even a story that tries to explain how they did
it (randomly generating s-boxes selecting the ones least vulnerable to the
attack).

~~~
Nelson69
Don Coppersmith wrote an article in the IBM system's journal that said as
much.

------
tomp
I wonder how many global sources of randomness they've discarded before
finding one that is both _plausibly safe_ and _exploitable_.

------
api
I get the concern with NIST but I'm unsure about the concern with Curve25519.
Is there any reason to suspect shenanigans there to be plausible?

Also I'm not sure that _future_ public lotteries are really that great.
_Technically_ such a thing could be rigged, though it would be hard. A truly
good source would be something cosmic and public like sunspot records in the
future that could be independently verified and recorded by multiple people
and could not be tampered with unless God wants to backdoor our crypto.

~~~
vessenes
Yes, I hate the idea of future public lotteries, published ahead of time. The
entire idea is to be resistant to a nation-state attack; lotteries seem pretty
far down the chain.

If you're in love with lotteries, you could do something like order all
lotteries in the world in a published list, and then choose them based on the
last digits of bitcoin block hashes over a certain period.

I'm not sure what bitrate you could get through sunspots, but I agree we
shouldn't worry about subversion from that angle.

~~~
baby
It's based on lotteries from different countries all around the world. No way
ONE state adversary could rig this. It's also set in the future, you need to
commit to the time frame where you'll be doing that. I think their plan was to
tweet it and sing it on soundcloud (among other things)

~~~
api
> No way ONE state adversary could rig this.

What about _multiple_ state adversaries? It would be hard as hell but it could
be done.

I'd still opt for an astronomical source. If God wants to backdoor our crypto
we're SOL, but other than that it would be pretty solid. I also don't get
what's wrong with nothing up my sleeve constants. Hashing the word "YOLO" is
mathematically unlikely to be a rigged constant to almost "probability of
falling through the floor due to random quantum fluctuations" degrees.

~~~
baby
> What about multiple state adversaries? It would be hard as hell but it could
> be done.

Highly unlikely, there is too much money in play, too many processes to
corrupt... Cryptography is usually made solid enough so that there are easier
ways to break the system.

[http://cryptoexperts.github.io/million-dollar-
curve/#lotteri...](http://cryptoexperts.github.io/million-dollar-
curve/#lotteries)

> what's wrong with nothing up my sleeve constants

It's not unpredictable. There are a million constants you could choose from if
you wanted to make a backdoor. I think the badass paper is about that.

------
red_admiral
Sigh, yet another attempt at solving the wrong problem.

There is no shortage of proposals for how to generate curves. There is a
shortage of implementations that you can just "npm install" or whatever and
use.

For ECC, I can name you one library that people like me can use - libsodium
based on djb's Curve/Ed25519. It got into the TLS standard not because it's so
much better than anything else but because it has an implementation that
works, is available for many languages and has decent documentation.

Of course it's helpful that djb spent a lot of time securing the thing against
side-channel/timing attacks and employed the best coding practices and writing
and presenting papers on the thing but no amount of writing papers is a
substitute for sitting down and actually building the thing in a "production
quality" way.

------
tonyhb
Elliptic curves are going to be rendered redundant with the introduction of
quantum computing via shor's algorithm.

25519 is already trusted and fast, and in all likelihood will probably last
until we need to shift from this type of cryptography.

Seems as though this is pretty futile and doesn't need to exist.

------
matt_wulfeck
From a practical point having sources of randomness/entropy isn't very useful.
A CSPRNG will do a great job generating random numbers. It will create secure
Tls connections and a ssh_key that's never been seen before. However it's
Achilles heel is that it MUST be seeded with random numbers. That's hard to do
in a predictable state, such as a headless vm.

If the seeds no good it can't establish a secure Tls connection to fetch
random data (ala Ubuntu pollinate service).

The next thing to push crypto security forward is easy, efficient, and
trustworthy ways to generate this seed.

~~~
tptacek
Yeah, you're missing the point a little. If you want to generate and
standardize a random curve (like, in this paper, the "random" version of
Curve25519, which doesn't rely on specific magic parameters carefully chosen
for speed), you have a big problem: even though your CSPRNG might be perfectly
fine, nobody is going to believe that you actually used it, because you can't
prove that you did.

Hence: lotteries.

------
cyphar
One thing that is ignored is that you can't be sure that a lottery isn't
rigged. We've seen cases (Serbia) where lotteries were rigged, so it's very
possible that someone with enough money could rig your entropy source.

~~~
daodedickinson
It's relatively rare that lotteries AREN'T rigged. It's a bunch of money
sitting RIGHT THERE to the people implementing the lottery. And like any other
situation where human beings have a GIGANTIC incentive to commit fraud, they
often do: [https://thehornnews.com/authorities-lottery-may-be-
rigged/](https://thehornnews.com/authorities-lottery-may-be-rigged/)
[http://www.nydailynews.com/news/national/lottery-
employees-r...](http://www.nydailynews.com/news/national/lottery-employees-
rigged-14-3-win-officials-article-1.2185601)

"State lotteries in Colorado, Wisconsin, and Oklahoma have confirmed they paid
jackpots worth $8 million to Tipton associates, including his old college
roommate, Robert Rhodes. Investigators are looking at payouts in the other 37
states and U.S. territories that used random-number generators from the Iowa-
based association, which administers games and distributes prizes for the
lottery consortium." NOTICE THAT 40+ STATES AND US TERRITORIES ACTUALLY USED
ONE RIGGED RNG FROM THIS CORRUPT DUDE IN IOWA

I don't know what they these curves are used for, but, if there is anything at
stake, it's worth looking into whether some of the people working on this
project had college roommates that are now in lottery sinecures.

------
imdsm
[https://simple.wikipedia.org/wiki/Elliptic_curve](https://simple.wikipedia.org/wiki/Elliptic_curve)
needs more input, so if anyone here is feeling up to it...

------
daodedickinson
Hahaha they haven't seen all the past instances of lotteries being rigged? And
they don't think it will happen in the future?

------
codezero
Is it conceivable that a government agency could manipulate lottery results
specifically to break this?

~~~
jlgaddis
cf. the FAQ

~~~
codezero
Doh, thanks!

------
PaulHoule
see
[https://en.wikipedia.org/wiki/Numbers_game](https://en.wikipedia.org/wiki/Numbers_game)

------
aagha
ELI5

------
yandrypozo
more garbage over the garbage !!

------
jdlyga
I'm donating 35 dollars to Million Dollar Curve. Who wants to match me?

