18 ms·

On the Impending Crypto Monoculture

322 points by tonyg 11y ago

daodedickinson 11y ago
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.
- NegativeK 11y ago
  I think the proper elaboration to "Don't roll your own" is "Don't roll your own when it matters." Attack the rolls of others and roll your own demo and ask for attacks.
- intrasight 11y ago
  crypto is less CS than Applied Math . When I was graduated, there was no such thing as a CS degree - it was called Applied Math. But even then, most Applied Math didn't require very sophisticated math. Crypto does.
  - RyanZAG 11y ago
    Agreed. People get the completely wrong idea simply because a computer is involved. It's the same as doing a black hole simulation - sure you have to code it up on a computer, but a CS student is not going to be able to do a full black hole simulation. You're going to need a physics phd, not even a physics student. Same for crypto - you need a crypto phd for a fully secure novel crypto implementation, not a cs student.
- baudehlo 11y ago
  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 11y ago
    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?
oconnore 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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?
tc 11y ago
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.
- stcredzero 11y ago
  But that would rather understate Linus' substantial contribution to thinking about version control differently and better. That paradigm of version control existed previously. (Monticello in Smalltalk, for example.) However, Linus had the programming chops and name recognition to start it off down the road to what it is today.
  - davidgerard 11y ago
    Most important, I think, was a great big urgent real-life use case (Linux) to optimise git toward. That's why it's really good at managing a Linux-sized codebase. (Most of what is annoying and difficult about git makes much more sense when you realise it was literally invented for Linus to handle his email, and anyone else having use for it is a serendipitious happenstance.)
- wtbob 11y ago
  I don't think it's so much about not wanting to give djb his due as wanting to point out that literally the rest of the industry is shamefully bad.
  - mtgx 11y ago
    That may be true, but I still think there's a negative undertone against DJB's crypto here, even if it's unintentional (if you're going to talk about a crypto monoculture, it may become inevitable to talk about DJB's work and its adoption). However, I worry many (developers) will get the wrong message from this post: that they shouldn't use the new standards from DJB (even if they are clearly superior in every way), because that would "help create the monoculture". Also look at how this post ends: > So the (pending) Bernstein monoculture isn't necessarily a vote for Dan, it's more a vote against everything else. So it's not a vote for Berstein that he got so much so right? If it's not a vote for DJB's work, then maybe he can point out what's wrong with it (other than everyone wanting to adopt it). The post could've very well ended like this, and it would've been better for it: > The impending monoculture (based around DJB's crypto) is showing us that we need simpler, more boring crypto everywhere, but it needs to come from other authors as well. Something like that. He is after all arguing against non-boring crypto throughout the post, no? So that should've been his conclusion? Maybe even add a little bit of "DJB has showed us the way - now it's time for others to pick up the torch and take it from here." But I imagine he wouldn't have gone that far.
RcouF1uZ4gsC 11y ago
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 11y ago
  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.
devit 11y ago
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.
- stcredzero 11y ago
  Then you're creating an unwieldy situation where analysis is very difficult. That's just an advanced form of security by obscurity. What you're saying is, that it's better to go in blind, wearing lots of armor and padding. That strategy works if your enemies don't have anything more potent than a knife. It absolutely doesn't work if they have guns and explosives. Better to clearly know what you're up against.
  - ocdtrekkie 11y ago
    I doubt devit was suggesting we stop analyzing the individual methods. If we (and to use a really stupid simple example on largely insecure functions because I'm a simpleton) hash something with... sha1(md5(things)) We can both study the relative security of sha1() and md5() separately, but also know that using both means that an attacker must defeat both methods. This isn't security by obscurity so much as security insurance. If either sha1() or md5() is compromised, the data is still protected by the other. Similarly, if we use ten different encryption methods on top of each other... we know a few things: - If we're studying all of those methods for flaws, the initial challenge of beating it is defeating all ten methods. - If a method is found to be compromised, our data is still protected by nine other methods. - At the very least, we've made brute forcing this a pain in the rear, because nine of those ten layers' output is probably really hard to tell are correct. If you have a crypto 'stack' of ten methods, and you find one is now easy to compromise, you can napkin math realize you've lost one layer of protection, so when a zero day happens on one method, you don't have to panic and assume all of your data is compromised. But your goal remains to ensure as many of those individual layers work against 'guns and explosives'.
tptacek 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      > 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 11y ago
zaroth 11y ago
Doesn't X25519 suffer from the same nonce-reuse issue?
- bascule 11y ago
  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.
  - zaroth 11y ago
    Sorry, don't know why I wrote that, I was thinking ChaCha20/Poly1305. OP picks on all the other AEAD modes for failing with nonce reuse, but doesn't mention it's actually the same failure mode with ChaCha20/Poly1305.
  - tptacek 11y ago
    Although, in fairness, misuse-resistance is a theme of EdDSA.
mtgx 11y ago
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_v._United_States https://en.wikipedia.org/wiki/Daniel_J._Bernstein#Bernstein_... 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-dream-machine/ https://www.technologyreview.com/s/544421/googles-quantum-dr... According to this, a 4,000 qubit computer will be able to break RSA 2048-bits: https://security.stackexchange.com/questions/87345/how-many-qubits-are-needed-to-factor-2048-bit-rsa-keys-on-a-quantum-computer https://security.stackexchange.com/questions/87345/how-many-... 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 11y ago
swordswinger12 11y ago
All of his problems with GCM are fixed in the recent modification, GCM-SIV. Can't standards bodies just add that?
- tptacek 11y ago
  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 11y ago
    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?
bascule 11y ago
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 11y ago
  They also missed the hilarious saga of the Crystalline cipher.
  - Laforet 11y ago
    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.html https://www.ietf.org/mail-archive/web/cfrg/current/msg06826....
    - CiPHPerCoder 11y ago
      This was my favorite response: https://www.ietf.org/mail-archive/web/cfrg/current/msg06805.html https://www.ietf.org/mail-archive/web/cfrg/current/msg06805....
yyin 11y ago
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.
nickpsecurity 11y ago
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.
aidenn0 11y ago
In the 90s we had one as well: MD5 RC4 RSA all share Ron Rivest as an author.
JoachimS 11y ago
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 11y ago
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 11y ago
  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.
red_admiral 11y ago
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 11y ago
  Nope. https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html
Mojah 11y ago
In case the source goes down, there's a public mirror online here: https://marc.ttias.be/cryptography-general/2016-03/msg00391.php https://marc.ttias.be/cryptography-general/2016-03/msg00391....
DyslexicAtheist 11y ago
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 11y ago
  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

322 points by tonyg 11y ago

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.

NegativeK 11y ago
I think the proper elaboration to "Don't roll your own" is "Don't roll your own when it matters." Attack the rolls of others and roll your own demo and ask for attacks.
intrasight 11y ago
crypto is less CS than Applied Math . When I was graduated, there was no such thing as a CS degree - it was called Applied Math. But even then, most Applied Math didn't require very sophisticated math. Crypto does.
- RyanZAG 11y ago
  Agreed. People get the completely wrong idea simply because a computer is involved. It's the same as doing a black hole simulation - sure you have to code it up on a computer, but a CS student is not going to be able to do a full black hole simulation. You're going to need a physics phd, not even a physics student. Same for crypto - you need a crypto phd for a fully secure novel crypto implementation, not a cs student.
baudehlo 11y ago
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 11y ago
  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?

oconnore 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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?

tc 11y ago

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.

stcredzero 11y ago
But that would rather understate Linus' substantial contribution to thinking about version control differently and better. That paradigm of version control existed previously. (Monticello in Smalltalk, for example.) However, Linus had the programming chops and name recognition to start it off down the road to what it is today.
- davidgerard 11y ago
  Most important, I think, was a great big urgent real-life use case (Linux) to optimise git toward. That's why it's really good at managing a Linux-sized codebase. (Most of what is annoying and difficult about git makes much more sense when you realise it was literally invented for Linus to handle his email, and anyone else having use for it is a serendipitious happenstance.)
wtbob 11y ago
I don't think it's so much about not wanting to give djb his due as wanting to point out that literally the rest of the industry is shamefully bad.
- mtgx 11y ago
  That may be true, but I still think there's a negative undertone against DJB's crypto here, even if it's unintentional (if you're going to talk about a crypto monoculture, it may become inevitable to talk about DJB's work and its adoption). However, I worry many (developers) will get the wrong message from this post: that they shouldn't use the new standards from DJB (even if they are clearly superior in every way), because that would "help create the monoculture". Also look at how this post ends: > So the (pending) Bernstein monoculture isn't necessarily a vote for Dan, it's more a vote against everything else. So it's not a vote for Berstein that he got so much so right? If it's not a vote for DJB's work, then maybe he can point out what's wrong with it (other than everyone wanting to adopt it). The post could've very well ended like this, and it would've been better for it: > The impending monoculture (based around DJB's crypto) is showing us that we need simpler, more boring crypto everywhere, but it needs to come from other authors as well. Something like that. He is after all arguing against non-boring crypto throughout the post, no? So that should've been his conclusion? Maybe even add a little bit of "DJB has showed us the way - now it's time for others to pick up the torch and take it from here." But I imagine he wouldn't have gone that far.

RcouF1uZ4gsC 11y ago

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 11y ago
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.

devit 11y ago

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.

stcredzero 11y ago
Then you're creating an unwieldy situation where analysis is very difficult. That's just an advanced form of security by obscurity. What you're saying is, that it's better to go in blind, wearing lots of armor and padding. That strategy works if your enemies don't have anything more potent than a knife. It absolutely doesn't work if they have guns and explosives. Better to clearly know what you're up against.
- ocdtrekkie 11y ago
  I doubt devit was suggesting we stop analyzing the individual methods. If we (and to use a really stupid simple example on largely insecure functions because I'm a simpleton) hash something with... sha1(md5(things)) We can both study the relative security of sha1() and md5() separately, but also know that using both means that an attacker must defeat both methods. This isn't security by obscurity so much as security insurance. If either sha1() or md5() is compromised, the data is still protected by the other. Similarly, if we use ten different encryption methods on top of each other... we know a few things: - If we're studying all of those methods for flaws, the initial challenge of beating it is defeating all ten methods. - If a method is found to be compromised, our data is still protected by nine other methods. - At the very least, we've made brute forcing this a pain in the rear, because nine of those ten layers' output is probably really hard to tell are correct. If you have a crypto 'stack' of ten methods, and you find one is now easy to compromise, you can napkin math realize you've lost one layer of protection, so when a zero day happens on one method, you don't have to panic and assume all of your data is compromised. But your goal remains to ensure as many of those individual layers work against 'guns and explosives'.

tptacek 11y ago

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 11y ago
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 11y ago
  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 11y ago
    > 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 11y ago

zaroth 11y ago

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

bascule 11y ago
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.
- zaroth 11y ago
  Sorry, don't know why I wrote that, I was thinking ChaCha20/Poly1305. OP picks on all the other AEAD modes for failing with nonce reuse, but doesn't mention it's actually the same failure mode with ChaCha20/Poly1305.
- tptacek 11y ago
  Although, in fairness, misuse-resistance is a theme of EdDSA.

mtgx 11y ago

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_v._United_States https://en.wikipedia.org/wiki/Daniel_J._Bernstein#Bernstein_... 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-dream-machine/ https://www.technologyreview.com/s/544421/googles-quantum-dr... According to this, a 4,000 qubit computer will be able to break RSA 2048-bits: https://security.stackexchange.com/questions/87345/how-many-qubits-are-needed-to-factor-2048-bit-rsa-keys-on-a-quantum-computer https://security.stackexchange.com/questions/87345/how-many-... 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 11y ago

swordswinger12 11y ago

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

tptacek 11y ago
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 11y ago
  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?

bascule 11y ago

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 11y ago
They also missed the hilarious saga of the Crystalline cipher.
- Laforet 11y ago
  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.html https://www.ietf.org/mail-archive/web/cfrg/current/msg06826....
  - CiPHPerCoder 11y ago
    This was my favorite response: https://www.ietf.org/mail-archive/web/cfrg/current/msg06805.html https://www.ietf.org/mail-archive/web/cfrg/current/msg06805....

yyin 11y ago

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.

nickpsecurity 11y ago

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.

aidenn0 11y ago

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

JoachimS 11y ago

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 11y ago

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 11y ago
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.

red_admiral 11y ago

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 11y ago
Nope. https://blog.cr.yp.to/20140323-ecdsa.html https://blog.cr.yp.to/20140323-ecdsa.html

Mojah 11y ago

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

DyslexicAtheist 11y ago

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 11y ago
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