
On the Impending Crypto Monoculture - tonyg
http://www.metzdowd.com/pipermail/cryptography/2016-March/028824.html
======
tptacek
This was an inevitable consequence of Bernstein being one of the very few
cryptographers simultaneously devoted to:

* Theoretical rigor

* Competitive performance ("new speed record for X" being a theme of his research)

* Misuse-resistant constructions and interfaces

He was doing this stuff before it was cool (he's as far as I can tell the only
cryptographer to have written something like qmail) and the rest of the
industry is struggling to catch up.

The list of Bernsteinisms is slightly less scary in context:

* Curve25519 and EdDSA are sort of related work, and the alternative in non-DJB cryptography would be "NIST P-curve and ECDSA over that P-curve". The consensus seems to be that Edwards curves are superior for a bunch of practical reasons, and Bernstein pioneered them, so: no surprise.

* Poly1305 and ChaCha20 are virtually never used independently; they can been seen as DJB's most current AEAD construction. There are plenty of competing AEADs; in fact, there's a competition (CAESAR) underway that DJB is involved in.

So really, that's not that much scarier than the fact that AES and SHA-3 share
an author.

~~~
nly
He's also pro-freedom. He's fought the US government in court. He goes to
hacker cons and mixes with us mortals. People who've met him tend to like and
trust him.

~~~
tptacek
I've met him (I'm in Chicago). I like him. But he is not the only
cryptographer with that reputation. Phil Rogaway has a similar reputation, and
went as far as to put a no-military-use patent on OCB.

~~~
wtbob
> Phil Rogaway has a similar reputation, and went as far as to put a no-
> military-use patent on OCB.

Had he not done that, it might be more useful. When it expires, maybe we'll
see it put to good use.

~~~
dtornabene
As someone who has a highly ambivalent attitude toward the military for very
real, legitimate reasons I'd love it if you could elaborate. I myself live
that way now, as in; I don't work for the military, anyone who subcontracts to
the military or the homeland security, etc. And it is precisely for reasons
that would push one to include a no-military-use patent on OCB. fwiw I'm not
_intimately_ familiar with the figures involved, I know who they are, read
some of bernsteins code/math/writing, and no vaguely who Rogaway is (but
haven't yet had a chance to read the "moral character" essay).

~~~
antod
It is basically incompatible with both Open Source and Free Software
definitions. ie:

"6\. No Discrimination Against Fields of Endeavor"
[https://en.wikipedia.org/wiki/The_Open_Source_Definition](https://en.wikipedia.org/wiki/The_Open_Source_Definition)

and

"The freedom to run the program as you wish, for any purpose (freedom 0)."
[https://en.wikipedia.org/wiki/The_Free_Software_Definition](https://en.wikipedia.org/wiki/The_Free_Software_Definition)

~~~
schoen
However, Rogaway also issued a separate patent license for free and open
source use (which does not exclude military uses).

[http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf](http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf)

So while it's true that free and open source software would not be able to
impose a no-military-use restriction, Rogaway in this case is exempting free
and open source projects from that restriction.

~~~
yarrel
Free and open source software don't allow that sort of restriction. So while
Rogaway's intentions are honorable, the results aren't coherent.

~~~
kerkeslager
I'm not 100% sure, but I think this is a choice of one of a few licenses for
the software rather than a dual license. The licenses aren't coherent if you
apply the licenses simultaneously, but I think only one of the licenses need
apply to the software for a given user.

So you can release free and open source software which might be used for
military purposes, OR you can release closed sourced software, but it can't be
used for military purposes. The effect is that if your software will be used
for military purposes you have to release it as free and open source software.

In this case it's not a dual license where you're bound by the terms of both
licenses, it's a situation where you choose one of the licenses based on which
set of terms you can comply with. Multi-option licenses like this are
frequently used for proprietary software to enforce tiered pricing (such as
nonprofit/personal/corporate licenses all applying to the same software but
different licensees).

This is my interpretation, but I'm not a lawyer. I wouldn't stake my business
on my interpretation without consulting a lawyer and neither should you.

------
oconnore
I figured someone who knows more about this (than me) would write a good reply
to this, and they did:

Ron Garret replies:

    
    
        Saying "How on earth did it come to this?” strongly implies
        that you think that the trend towards DJB’s crypto suite a
        problem, but you don’t offer much in terms of proposals for
        how to solve it, or even what a solution would look like.
        You seem to agree that a solution would *not* look like the
        status quo.  So what exactly are you advocating here?
        
        I submit that the impending monoculture in crypto is not
        necessarily a problem, any more than the monoculture in
        physics (what?  No alternatives to GR and QM?) or climate
        science is necessarily a problem.  It’s possible that crypto
        has a Right Answer, and that Dan Bernstein has discovered/
        invented it.  If you believe that simplicity and minimalism
        ought to be part of the quality metric then there may be very
        few local maxima in the design space, and DJB may simply have
        found one of them.
        
        rg

~~~
skywhopper
Unfortunately, this argument doesn't really make sense. Just like decades of
software development (should) have taught us, and just like fighting climate
change, doing physics research, giving antibiotics, fighting terrorists,
criminals, spammers, enemy armies, eating healthy, raising kids, whatever--
multiple approaches and techniques and tools are _always_ a good thing. Why
would crypto be the one single area of life where there was a Right Answer?
The fact that crypto is part of an arms race with criminals and authoritarian
governments is strong evidence that a monoculture is _not_ the right approach.

~~~
tptacek
It is demonstrably not the case that diversity in cryptographic constructions
is always a good thing. What it usually results in is a diversity of single
points of failure.

~~~
adt2bt
Great point. When selecting a crypto approach, it makes no sense to not choose
what is apparently "the best" at this time.

However, is there a legitimate concern that we're collectively hoping DJB
hasn't messed anything up? I'm no expert in the area, but are there ways to
prove that his work is correct?

~~~
wolf550e
Many people have tried to find flaws in his math. DJB and friends now work on
formal verification of implementations.

------
RcouF1uZ4gsC
If we are talking about crypto monoculture, don't AES and SHA-3 come from Joan
Daemen? Also before this, the 90's crypto was basically a Ron Rivest
monoculture with RC4 and RSA. This is nothing new and I believe today's
monoculture is more secure than previous ones. Also, just like DES, RSA and
RCA got displaced, so will DJB's monoculture if something more secure comes
along.

Basically this monoculture is a consequence that crypto is very subtle and it
is often better to have 1 algorithm than everybody uses implements and studies
and tries to break rather than 10 that nobody really studies.

~~~
conceit
You couldn't possibly mean that enough people are working on it and that
monoculture is fine, with that argument.

You just state the status quo, but make it sound like a good thing, but the
impliciy reason is, that there aren't enough capable people, at least not
interested ones.

------
tc
Knew before clicking that this was going to be about DJB having won.

Peter Gutmann definitely has the credibility to make this critique. But saying
that DJB having won is more a vote against other crypto than a vote for Dan is
like saying that Git having won is more a vote against other SCMs than a vote
for Linus.

Well sure, you could say that. But that would rather understate Linus'
substantial contribution to thinking about version control differently and
better.

Similarly DJB has won because he led the way in thinking about the crypto
problem correctly. Peter basically acknowledges the underlying facts here, but
seems to not want to give Dan his due.

~~~
panic
Distributed version control wasn't Linus's idea. BitKeeper, Arch, Monotone and
darcs did it first, and in some ways better. But they all had problems:
BitKeeper was proprietary, Arch was baroque and difficult to use, and Monotone
and darcs had poor performance (darcs egregiously so, with an unfortunately-
easy-to-hit exponential-time edge case in their merging algorithm). Using Git
was a vote against these systems. But there's also not as much of a DVCS
monoculture: Bazaar and Mercurial are also used quite often, and could be
adopted quickly if git were to implode for some reason.

~~~
ams6110
_Arch was baroque and difficult to use_

More than git? I shudder at the thought.

~~~
dave2000
I thought it was just me. Anything more than the basic commands and I get
confused and have to look it up. Git is certainly popular -perhaps for many
it's the first version control system they've used-and is very fast, but would
you say it's well designed from a user perspective?

~~~
KingMob
No, git is a UI disaster. _Some_ of the complexity is necessary due to moving
to a distributed model of version control, but _most_ of it is lack of clarity
in designing the CLI.

Is anyone who's used Mercurial able to comment on the UI differences?

------
devit
One the solutions is to start using algorithm cascades instead of single
algorithms where performance doesn't matter.

If you are using 10 ciphers or 10 hash functions or 10 signature schemes, then
you need 10 different breakthroughs before it all falls down.

There is really no reason to not do this unless performance is important, and
a lot of times performance does not really matter.

NOTE: obviously you need to this properly and use a different key for each
cipher, concatenate hashes, concatenate signatures and so on. Also, you should
start encrypting with the best implemented ciphers, so that plaintext is not
leaked if the worst ciphers happen to have timing/cache vulnerabilities.

~~~
tptacek
Since cryptosystems designed by experts virtually never use cipher cascades,
having one is a pretty good indicator that your system hasn't been designed by
an expert.

More importantly: Guttman's argument isn't that it's _unsafe_ that we have
this "monoculture" (how would that work? DJB turns evil and reveals the secret
trapdoor in Curve25519?) --- it's that it's sad that things ended up this way.

~~~
derefr
> how would that work?

I can imagine a hypothetical world where DJB creates three crypto building-
blocks, gets hailed as the next coming of Alan Turing, and then we don't do
nearly the fact-checking we should when he creates a fourth, and it ends up
having a horrible flaw.

That seems to be half of what this article is warning against: a blind
optimistic trust that anything that DJB creates in the future will be perfect.
It's not that he's an infallible god of cryptography; it's that everyone else
is making obvious mistakes, and he at least has eyes.

~~~
habitue
If you look at backdoored algorithms, there are red flags all over the place.
A hallmark of DJB algorithms is that they use minimal constants that satisfy
publicly declared constraints. If you look at the spec for DUAL_EC_DRBG, the
backdoored rng standard, the first thing that you notice is that the constants
have no explanation for how they were derived, and that they are large enough
to hide a cryptographic key in.

If DJB releases a crypto algorithm with huge glaringly unexplained constants,
you'd better believe people will ask questions. I don't think it's possible to
both use "nothing up your sleeve numbers"[1] and to backdoor an algorithm.
You'd likely need the computing power needed to brute force the EC in the
first place in order to do it.

[1]
[https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number](https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number)

~~~
tptacek
It's funny that you would say this.

* During the recent CFRG curve selection debacle, Microsoft pushed for a noncompatible variant to Curve25519 (now called "PinkBikeShed") on the basis of it having minimal parameters.

* One of DJB's more notorious research papers, BADA55, is about the extent to which reliance on "easily explained math constants" is _not_ actually safe.

Also: the problem with Dual_EC is that it's a public key RNG. It's a
construction that has no reason to exist. The reason you don't have to worry
about DJB's (or Rogaway's or Shay Gueron's or whatever) documents having the
Dual_EC problem is that none of them are going to propose a public key RNG.

~~~
habitue
Thanks for the pointer to BADA55, I had not seen that.

Do you think it's possible for constants (selected in the way the constants
for ed25519 were selected) to be backdoored ala BADA55? It seems the
vulnerabilities come from using hashing algorithms on some small constant, not
from the constant itself being something simply constructed.

Also, it looks like DJB did alight on PinkBikeShed originally[1] but rejected
it for technical reasons. (Reasons I can't evaluate myself). Is my
understanding correct that the PinkBikeShed curve has more minimal parameters
than ed25519, but that it doesn't satisfy all of the security criteria that
ed25519 does?

[1] [https://www.ietf.org/mail-
archive/web/cfrg/current/msg05745....](https://www.ietf.org/mail-
archive/web/cfrg/current/msg05745.html)

~~~
tptacek
There is a very fiddly technical reason why PinkBikeShed is more user-friendly
than Curve25519. Bernstein would say that it's a powerful security argument,
but it's more of a nice- to- have than a must-have. Curve25519 won because it
had an installed base.

~~~
CiPHPerCoder
For anyone following this part of the comment thread, the mailing list
discussion about these topics is worth a read too:

[https://www.ietf.org/mail-
archive/web/cfrg/current/msg05619....](https://www.ietf.org/mail-
archive/web/cfrg/current/msg05619.html)

~~~
acqq
The text sketches a proof how PinkBikeShed from Microsoft is worse.

He also ends with "I didn't bother writing down a comprehensive critique of
PinkBikeShed, and didn't imagine that anyone would ever try to revive that
curve."

~~~
tptacek
It's a whole lot of sentences for a very simple difference. I think "proof" is
pushing it a bit far.

~~~
acqq
He wrote a lot, but it's very clear what his principles in this case are. To
be constructive, other experts should either point to the principles with
which they disagree or if they do agree point to the errors in his use of
them.

~~~
tptacek
In that argument, Microsoft would say that performance being equal, it's more
important for parameters to be minimal so that the curve is maximally rigid
and trustworthy. Bernstein would say that it's more important that there are
no implementation pitfalls, even very subtle ones that will be hard to
exploit.

I agree with Bernstein but I won't pretend it's a _totally_ cut and dried
argument.

What won the argument wasn't so much the merits of Bernstein's case, but that
Microsoft was in effect arguing for something that would break compatibility
with the 25519 installed base.

------
daodedickinson
As a young person new to computer science who was originally very curious
about crypto, I can say that all the admonitions against "rolling your own" is
intimidating people from entering the sector. When I'm shown a gigantic tome
on the topic and then told even if I know it inside and out I better not build
and use anything from it for real, I figure I may as well go in another
direction where if I do anything worse than the best I'm not committing a
heinous mistake.

So, compared to many sectors of computer science, much more patience and
willingness to toil for years before creating anything of use is required.

~~~
baudehlo
The problem is crypto is far more important than the performance of a sort
algorithm, or any other standard comp-sci algorithm.

And it's hard. I've been in this industry over 20 years, and been involved in
a bunch of high-ish profile stuff, but I know that I don't have the knowledge
to touch this stuff.

But in fairness it's a combination of understanding maths and understand some
low level CPU stuff. If you are into that, just start learning it. Practice
it. Someone has to follow on all this work. It could be you. But if it isn't,
there's a ton of interesting stuff out there that isn't crypto. (Although I'd
prefer everyone understood the basics of crypto, but that won't happen in my
lifetime).

~~~
daodedickinson
Yeah, it's really hard, and so I'm not smart enough to see what the author
might be comparing crypto with. What's something equally hard, but has far
less of a monoculture?

------
red_admiral
Minor nitpick with the first paragraph:

"A major feature of these changes includes the dropping of traditional
encryption algorithms and mechanisms like RSA, DH, ECDH/ECDSA, SHA-2, and AES,
for a completely different set of mechanisms, including Curve25519 (designed
by Dan Bernstein et al), EdDSA (Bernstein and colleagues), Poly1305 (Bernstein
again) and ChaCha20 (by, you guessed it, Bernstein)."

Curve25519 is an implementation of a cryptographic group. (EC)DH is an
agorithm that you can run over such a group. In fact, when you do key exchange
the recommended way in libsodium, you're doing DH key exchange over
Curve25519. (ECDH is simply "DH performed over an elliptic curve".)

Isn't EdDSA just ECDSA (which is again an algorithm) performed over a group
that happens to be a curve in Edwards form?

Put another way, the basic maths of DH key exchange is that you have a vector
space of "points" (vectors), you can add one point to another to get a new
point and you can multiply a point with an integer to get another point.

DH key exchange starts with an agreed-on point P. Person A picks a secret x
and sends x * P to B. Person B picks a secret y and sends y * P to B. Now A
has x and y * P so can compute x * (y * P) = (xy) * P while B computes y * (x
* P) = (xy) * P.

If the vector space is a certain kind of subgroup of Z ^ * _ p then this is
called DH. If the vector space is an elliptic curve group we call it ECDH.
Presumably if the elliptic curve is in Edwards form we should call it EdDH.
But the DH algorithm is by and large the same idea in each case - you could
happily define an interface for the vector space and then implement the key
exchange part once over this interface, which would let you link the same KEX
code against different implementations for ECDH, EdDH etc.

The same applies as far as I know for DSA/ECDSA/EdDSA.

~~~
tptacek
Nope.

[https://blog.cr.yp.to/20140323-ecdsa.html](https://blog.cr.yp.to/20140323-ecdsa.html)

------
aidenn0
In the 90s we had one as well: MD5 RC4 RSA all share Ron Rivest as an author.

------
bascule
Anyone (not saying Gutmann) who thinks djb's algorithms have been adopted due
to "rampant fanboyism" missed the years of debates about elliptic curves that
happened on the IRTF CFRG mailing list (primarily involving Microsoft).

~~~
CiPHPerCoder
They also missed the hilarious saga of the Crystalline cipher.

~~~
Laforet
Never heard about this before so I read it up on the cfrg list and oh dear it
was phenomenal.

[https://www.ietf.org/mail-
archive/web/cfrg/current/msg06826....](https://www.ietf.org/mail-
archive/web/cfrg/current/msg06826.html)

~~~
CiPHPerCoder
This was my favorite response:

[https://www.ietf.org/mail-
archive/web/cfrg/current/msg06805....](https://www.ietf.org/mail-
archive/web/cfrg/current/msg06805.html)

------
nickpsecurity
This is no surprise as I rallied against the monocultures and terrible
implementations before. I certainly did benefit from thr concept of misuse-
resistant crypto. I usually thought of this as a requirement or implementation
issue (a la Design-by-Contract specs). Never thought to design the crypto
system itself for this or maybe did but fleeting. I'll have to think on that
more.

------
yyin
I can think of worse outcomes than having to use djb's software, whether it's
dummy-proof libraries, well-designed, small programs that work together, or
algorithms chosen as defaults by some self-authorized standards group or by a
company selling bloated, proprietary software that only works with other
programs written by that company.

------
DyslexicAtheist
if you look at DJB code from qmail, djbdns and his other projects you know why
this is not a problem but a good thing (when compared to other projects like
openSSL or even MTA's like postfix where many contributors need to find a
compromise and align themselves).

the truth is that we are all brainwashed for pair-programming and working in
an agile pressure-cooker without code ownership. But if you look at the
quality of the work and code one single strong software architect can deliver
precisely because they didn't have to compromise with other stakeholders it is
clear why the result may be better.

I'm not saying that this is always true. But I have seen it times and times
again where a single individual built a whole platform that simply worked
mainly because he had the freedom to do so uninterrupted.

~~~
DyslexicAtheist
DJB delivered a really good 32C3 talk last December on post-quantum crypto
which touches the subject of design quite well:
[https://media.ccc.de/v/32c3-7210-pqchacks](https://media.ccc.de/v/32c3-7210-pqchacks)

------
JoachimS
If the situation was that ciper suites based on NIST algorithms were being
forced out from TLS and replaced with the new suites I might have agreed. But
that is not the case. The new cipher suites with new algorithms (yes developed
by DJB) just adds to the suites availble. They present an alternative to the
NIST monoculture. Complement, not replace.

Also, there is now a cipher suite with AES in OCB mode. And the licensing
terms as stated in the ITEF IPR disclosures makes the mode easier to use.
There are also a draft for Argon2 as KDF (an algorithm not by DJB).

I was more worried when everything seemed to end up being based on AES. Not
because its a bad algorithm, but beacuse we didn't have a fallback. That is
actually why the ChaCha-Poly1306 suite came about. RC4 was no longer a usable
fallback for AES.

------
emmelaich
Sort of related .. I had to upgrade our Kerberos crypto to something strong
enough yet something that both Windows 2012 and Java supported.

There is only _one_ option: AES128. It was quite surprising to me, though I'm
very far from a crypto expert.

AES256 is also possible _if_ you get the extra strength Java crypto libs.

~~~
xorcist
AES128 is not going to be your weakest link. Ever.

And there is no reason to believe AES256 is stronger than AES128. There have
been attacks against the former which are not applicable to the latter, and
the key length is enough.

------
Mojah
In case the source goes down, there's a public mirror online here:
[https://marc.ttias.be/cryptography-
general/2016-03/msg00391....](https://marc.ttias.be/cryptography-
general/2016-03/msg00391.php)

------
zaroth
Doesn't X25519 suffer from the same nonce-reuse issue?

~~~
bascule
X25519 is an elliptic curve Diffie-Hellman function and doesn't take a nonce.
If you're asking about ChaCha20... yes, which is why nonce reuse misuse
resistance is an important theme of CAESAR.

~~~
tptacek
Although, in fairness, misuse-resistance is a theme of EdDSA.

------
swordswinger12
All of his problems with GCM are fixed in the recent modification, GCM-SIV.
Can't standards bodies just add that?

~~~
tptacek
GCM and GCM-SIV are different constructions. GCM-SIV isn't the latest version
of GCM.

GCM-SIV is good, but it doesn't address _all_ the problems of GCM. You still
need hardware support to get a safe, efficient GCM-SIV.

GCM-SIV is also _way_ more complicated than Chacha20+Poly1305.

~~~
swordswinger12
It's clear that they're different constructions. The two papers don't even
share an author.

Why do you need hardware support for GCM-SIV?

------
mtgx
I think DJB has been a _visionary_ in cryptography, as much as someone can be
a visionary in this field. He saw software and encryption as free speech and
fought the U.S. government for it (he was only 24 at the time - how many of
you are/were willing to take on the US government at 24?)

[https://en.wikipedia.org/wiki/Daniel_J._Bernstein#Bernstein_...](https://en.wikipedia.org/wiki/Daniel_J._Bernstein#Bernstein_v._United_States)

He created all of this boring crypto that everyone wants to use now ahead of
most. He even launched a site around the sole idea of post-quantum
cryptography _8 years ago_ , because he thought it's that important and we
needed to start worrying about it then, if not earlier.

[https://pqcrypto.org/](https://pqcrypto.org/)

Most cryptographers started paying attention to PQ crypto only after the NSA
said we should worry about it, _last year_ (because obviously we should all
wait until the NSA bestows its knowledge and guidance upon us before doing
anything). But even then it's more of a _mild_ worry, as I'm not seeing the
crypto community act too panicked about it, despite the fact that we probably
have only about 5 years to figure out some fast and resilient algorithms and
protocols, another 5 years to test them, and another 5 to deploy them
worldwide.

Because in about 15 years quantum computers will probably be strong enough to
break conventional encryption. I think Google expects to have a 100-qubit
universal QC around 2018, and from there it should scale up easily (possibly
at a rate of 2-4x every 2 years, if it's similar to D-WAVE's progress).

[https://www.technologyreview.com/s/544421/googles-quantum-
dr...](https://www.technologyreview.com/s/544421/googles-quantum-dream-
machine/)

According to this, a 4,000 qubit computer will be able to break RSA 2048-bits:

[https://security.stackexchange.com/questions/87345/how-
many-...](https://security.stackexchange.com/questions/87345/how-many-qubits-
are-needed-to-factor-2048-bit-rsa-keys-on-a-quantum-computer)

If we get a 100-qubit in 2018 and then double-up the qubits every 2 years,
then we'll have a 6400 qubits quantum computer in 2032. Maybe it will happen
sooner, maybe it will happen 10 years later than predicted (although many seem
to be predicting a large enough to be useful universal quantum computer within
10 years), but either way we don't have much time left to figure this out.

So I guess my point is - _don 't give DJB the opportunity_ to create yet
another "monoculture" by allowing him to stand alone in paving the road for PQ
crypto. Because if he does, and 15 years from now we end up adopting his PQ
crypto, too, then you can't come complaining again about using "too much DJB
crypto".

~~~
Ar-Curunir
Post quantum crypto has been around for a while. Lattice based crypto was
introduced in the late 90s.

