10 ms·

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 h

by tc 10y 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 10y 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 10y 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 10y 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 10y 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.
  - tptacek 10y ago
    The author of this post is a cryptographer. The people who select ciphers for products are almost invariably not cryptographers. The idea that DJB crypto is selected simply because it is "clearly superior in every way" seems inaccurate. In fact, I think it's comments like these that set people like Guttman off. If you pay enough attention to the people who select but don't design ciphers --- ie, non-cryptographer engineers --- you're starting to hear more and more of a drumbeat of "do whatever DJB says"; if you push those people to explain those decisions, you don't usually get good answers.
    - napoleond 10y ago
      And yet, that drumbeat is probably a good thing. And perpetuated by people like you chanting "just use NaCl" every chance you get. So it's not super fair to pick on non-crypto geeks for accepting that easy truth.
      - tptacek 10y ago
        We're not talking about what library to use; we're talking about what algorithms go into standards.
    - CiPHPerCoder 10y ago
      > If you pay enough attention to the people who select but don't design ciphers --- ie, non-cryptographer engineers --- you're starting to hear more and more of a drumbeat of "do whatever DJB says"; if you push those people to explain those decisions, you don't usually get good answers. Sure. I like to call that condition "secure by default". Said engineers most often don't have a lot of knowledge and experience with cryptography, so they opt for the best option available. In a lot of cases, it's DJB's work. In other cases, it's someone who followed his example (e.g. the BLAKE(2) team). Also, this might have had something to do with this shift towards the current situation: https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad > Use, in order of preference: (1) The Nacl/libsodium default > If you can just use Nacl, use Nacl. You don't even have to care what Nacl does.
panic 10y ago
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.
- haberman 10y ago
  Arch also had terrible performance. The primary objects that lived in repositories were changesets, which every client downloaded as .tgz files IIRC, and then replayed locally to reach the current state. The primary innovation of both git and Mercurial was performance. Git is a highly optimized content-addressable database with version control built on top.
- ams6110 10y ago
  Arch was baroque and difficult to use More than git? I shudder at the thought.
  - panic 10y ago
    Well, just to give you a taste, here's an excerpt from "Revision Control with Arch: Introduction to Arch" in Linux Journal (http://www.linuxjournal.com/article/7671 http://www.linuxjournal.com/article/7671): In Arch, a changeset is represented as a directory tree full of bookkeeping files, patches, new files and removed files. The best contribution technique is to create a changeset directory and then tar it up for delivery: $ tla changes -o ,,new-robot-comment $ tar czvf my-changes.tar.gz ,,new-robot-comment/ Arch ignores files beginning with two commas, an equal sign and a few other special characters. By using a ,, at the start of our changeset directory name, we avoid the annoyance of Arch complaining that our new directory doesn't exist in the archive. It is probably good practice to use your e-mail address or some other identifier in the tarball filename and changeset directory name.
  - 10y ago

by tc 10y ago

stcredzero 10y 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 10y 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 10y 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 10y 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.
- tptacek 10y ago
  The author of this post is a cryptographer. The people who select ciphers for products are almost invariably not cryptographers. The idea that DJB crypto is selected simply because it is "clearly superior in every way" seems inaccurate. In fact, I think it's comments like these that set people like Guttman off. If you pay enough attention to the people who select but don't design ciphers --- ie, non-cryptographer engineers --- you're starting to hear more and more of a drumbeat of "do whatever DJB says"; if you push those people to explain those decisions, you don't usually get good answers.
  - napoleond 10y ago
    And yet, that drumbeat is probably a good thing. And perpetuated by people like you chanting "just use NaCl" every chance you get. So it's not super fair to pick on non-crypto geeks for accepting that easy truth.
    - tptacek 10y ago
      We're not talking about what library to use; we're talking about what algorithms go into standards.
  - CiPHPerCoder 10y ago
    > If you pay enough attention to the people who select but don't design ciphers --- ie, non-cryptographer engineers --- you're starting to hear more and more of a drumbeat of "do whatever DJB says"; if you push those people to explain those decisions, you don't usually get good answers. Sure. I like to call that condition "secure by default". Said engineers most often don't have a lot of knowledge and experience with cryptography, so they opt for the best option available. In a lot of cases, it's DJB's work. In other cases, it's someone who followed his example (e.g. the BLAKE(2) team). Also, this might have had something to do with this shift towards the current situation: https://gist.github.com/tqbf/be58d2d39690c3b366ad https://gist.github.com/tqbf/be58d2d39690c3b366ad > Use, in order of preference: (1) The Nacl/libsodium default > If you can just use Nacl, use Nacl. You don't even have to care what Nacl does.

panic 10y ago

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.

haberman 10y ago
Arch also had terrible performance. The primary objects that lived in repositories were changesets, which every client downloaded as .tgz files IIRC, and then replayed locally to reach the current state. The primary innovation of both git and Mercurial was performance. Git is a highly optimized content-addressable database with version control built on top.
ams6110 10y ago
Arch was baroque and difficult to use More than git? I shudder at the thought.
- panic 10y ago
  Well, just to give you a taste, here's an excerpt from "Revision Control with Arch: Introduction to Arch" in Linux Journal (http://www.linuxjournal.com/article/7671 http://www.linuxjournal.com/article/7671): In Arch, a changeset is represented as a directory tree full of bookkeeping files, patches, new files and removed files. The best contribution technique is to create a changeset directory and then tar it up for delivery: $ tla changes -o ,,new-robot-comment $ tar czvf my-changes.tar.gz ,,new-robot-comment/ Arch ignores files beginning with two commas, an equal sign and a few other special characters. By using a ,, at the start of our changeset directory name, we avoid the annoyance of Arch complaining that our new directory doesn't exist in the archive. It is probably good practice to use your e-mail address or some other identifier in the tarball filename and changeset directory name.
- 10y ago