11 ms·

"if you roll your own crypto, and it breaks, you will look incompetent." - tptacek to cperciva, 313 days ago. http://news.ycombinator.com/item?id=1183757 http:

"if you roll your own crypto, and it breaks, you will look incompetent." - tptacek to cperciva, 313 days ago. http://news.ycombinator.com/item?id=1183757 http://news.ycombinator.com/item?id=1183757 (not that I know anything about crypto)

tptacek 16y ago
I was pretty mean to Colin in that post. In the intervening year I've come to respect Colin's practical experience a lot more than I did before, when I thought he was hopelessly academic. I'd like to make it clear that Colin doesn't look incompetant (actually, he seems to be earning accolades from the Twitterverse for how he wrote it up). But yeah, I hope it's obvious that I see this as a very strong vindication for my argument that generalist devs shouldn't build crypto. At all, ever. Use TLS for data in motion; use PGP for data at rest. Systems much bigger and heavier than yours have gotten away with this.
- djcapelis 16y ago
  Colin is wildly competent, but I was always uncomfortable with how much he was willing to do his own work without review. He is probably one of the best people in the world to do this work, but even the best person in the world will occasionally make mistakes, as happened here. Generalist devs shouldn't build crypto. Expert devs shouldn't build crypto without review. As for academics... a lot of us aren't as hopeless as some of the trash that appears in conferences and journals might appear. :)
  - ericb 16y ago
    > Expert devs shouldn't build crypto without review. I was surprised that Colin's solution is to personally re-review his code. Good writers know--don't rely on yourself for proofreading. Usually the mental lapse that caused the problem will manifest itself during your review as well. Disclaimer: I am not a tarsnap user.
    - cperciva 16y ago
      In my experience, I'm very good at proofreading my own writing/code, as long as I wait long enough that I've forgotten it. In this case, I was looking at code which I wrote over a year ago. But please, go ahead and give the code another read. :-)
      - djcapelis 16y ago
        I sense a great justification for an alcohol budget. Edit: Totally willing to continue burning karma on this comment if the HN community continues to decide vote it down. I've tried reviewing my own code in a different state of intoxication than when I wrote it and I'm not joking that it can help. I'm still trying to pull resources together for a study on the benefit of different mindframes for peer review. We haven't tried alcohol yet, but frankly it wouldn't be a half bad idea if we could get anyone not to laugh too loudly at the proposal.
        cperciva 16y ago
        Cute idea, but I don't drink (for medical reasons). I suppose I could try reviewing code in both caffeinated and decaffeinated states, but being decaffeinated gives me enough of a headache that I don't think I'd be much use that way.
        steveklabnik 16y ago
        There's some sort of analogy in here about how alcohol 'loosens you up' could be related to getting in the proper state of mind to 'code fearlessly,' but I can't seem to find it.
        Kliment 16y ago
        It was referenced in http://xkcd.com/323/ http://xkcd.com/323/ but I can't find a proper reference either.
        ryanwaggoner 16y ago
        Not only code review, but also useful for UI design. Drink 12 beers and then try to use the app you just designed :)
- eru 16y ago
  > Use TLS for data in motion; use PGP for data at rest. That's useful advice, if you need and _want_ the guarantees given by TLS or PGP. If you have other needs then a look at, say, off-the-record messaging may be useful.
  - tptacek 16y ago
    I think it's a bad idea to recommend the OTR protocol to people looking for a simple encrypted transport (or simple encrypted record storage). How do you judge whether the guarantees TLS offers are "needed" or not?
    - eru 16y ago
      That judgment is partly outside the more mechanical parts of cryptography. You have to see what your application domain demands. OTR is just the first example I could think of, that gives different guarantees than most normal cryptosystems. I don't particularly recommend it for anything apart from instant messaging. And I wouldn't recommend implementing your own. If I speak to you in private (and we know each other), you can be sure you are speaking to me, but you won't be able to proof to any third party anything I said. OTR can give you something like that. PGP can't. For most application you will be well served with PGP or TLS. But be aware of what baggage they bring. For some areas losing deniability via PGP can be worse than plain text.
      - tptacek 16y ago
        This is a counterfeit argument. PGP loses "deniability" (and "forward secrecy") if by PGP you mean "the PGP user interface". But if what you mean is simply "the PGP cryptosystem" and "the PGP message format of packets and bulk encryption and signatures", then you can grant your system most any property OTR gives you. This is a moot point, because most systems would never care enough to intricately position all their features just-so to compose OTR-like features out of PGP primitives. What they need is to be able to encrypt anything without implementing trivially exploitable crypto vulnerabilities that were discovered and solved decades ago. This is a textbook case of everyone's good being strangled by someone's opinion of the perfect.
alnayyir 16y ago
>(not that I know anything about crypto) Me either, and while I chuckled, I think cperciva is one of the better qualified people to be implementing crypto.
- djcapelis 16y ago
  No one is qualified to implement crypto without review. cperciva is extremely qualified to implement crypto, but not without review. I think it is wise that he has implemented a bug bounty procedure. He should make sure it applies to unreleased versions too so maybe someone will put an RSS feed of his SCM checkins into their RSS reader and try and catch bugs as he's making them. :) It would be nice if he had the money to spring for paying someone else to look at all his changes, but alas... that stuff is expensive!
  - tptacek 16y ago
    Bug bounties are not reviews. No professional is going to undertake a review on spec. The demand for software security is too high; most of us have our pick of interesting projects that will pay whether we find something or not. We're not unique in that respect; top iPhone developers won't work for you on spec either, not because spec is evil, but because the economics don't work. Furthermore, you can pay $1000 for XSS bugs and random memory corruption flaws in browsers because fuzzers can find them, because they're luck-of-the-draw findings, and because people are hammering those things whether you pay them or not. But $1000 doesn't pay for a day of qualified review, and no qualified reviewer would suggest less than two weeks for something like Tarsnap.
    - djcapelis 16y ago
      I agree on all of this. However, since Colin presumably doesn't want to raise his prices to pay for actual review, it is encouraging that he is at least going with bug bounties. These, at the very least, gives us a good excuse to assign them as fun things to do for graduate students with some hope that one will want to procrastinate so hard that they will actually look at the code. Also I think any reviewer who wanted to get paid would not start with Colin's code as an easy place to find bugs.

tptacek 16y ago

I was pretty mean to Colin in that post. In the intervening year I've come to respect Colin's practical experience a lot more than I did before, when I thought he was hopelessly academic. I'd like to make it clear that Colin doesn't look incompetant (actually, he seems to be earning accolades from the Twitterverse for how he wrote it up). But yeah, I hope it's obvious that I see this as a very strong vindication for my argument that generalist devs shouldn't build crypto. At all, ever. Use TLS for data in motion; use PGP for data at rest. Systems much bigger and heavier than yours have gotten away with this.

djcapelis 16y ago
Colin is wildly competent, but I was always uncomfortable with how much he was willing to do his own work without review. He is probably one of the best people in the world to do this work, but even the best person in the world will occasionally make mistakes, as happened here. Generalist devs shouldn't build crypto. Expert devs shouldn't build crypto without review. As for academics... a lot of us aren't as hopeless as some of the trash that appears in conferences and journals might appear. :)
- ericb 16y ago
  > Expert devs shouldn't build crypto without review. I was surprised that Colin's solution is to personally re-review his code. Good writers know--don't rely on yourself for proofreading. Usually the mental lapse that caused the problem will manifest itself during your review as well. Disclaimer: I am not a tarsnap user.
  - cperciva 16y ago
    In my experience, I'm very good at proofreading my own writing/code, as long as I wait long enough that I've forgotten it. In this case, I was looking at code which I wrote over a year ago. But please, go ahead and give the code another read. :-)
    - djcapelis 16y ago
      I sense a great justification for an alcohol budget. Edit: Totally willing to continue burning karma on this comment if the HN community continues to decide vote it down. I've tried reviewing my own code in a different state of intoxication than when I wrote it and I'm not joking that it can help. I'm still trying to pull resources together for a study on the benefit of different mindframes for peer review. We haven't tried alcohol yet, but frankly it wouldn't be a half bad idea if we could get anyone not to laugh too loudly at the proposal.
      - cperciva 16y ago
        Cute idea, but I don't drink (for medical reasons). I suppose I could try reviewing code in both caffeinated and decaffeinated states, but being decaffeinated gives me enough of a headache that I don't think I'd be much use that way.
      - steveklabnik 16y ago
        There's some sort of analogy in here about how alcohol 'loosens you up' could be related to getting in the proper state of mind to 'code fearlessly,' but I can't seem to find it.
        Kliment 16y ago
        It was referenced in http://xkcd.com/323/ http://xkcd.com/323/ but I can't find a proper reference either.
      - ryanwaggoner 16y ago
        Not only code review, but also useful for UI design. Drink 12 beers and then try to use the app you just designed :)
eru 16y ago
> Use TLS for data in motion; use PGP for data at rest. That's useful advice, if you need and _want_ the guarantees given by TLS or PGP. If you have other needs then a look at, say, off-the-record messaging may be useful.
- tptacek 16y ago
  I think it's a bad idea to recommend the OTR protocol to people looking for a simple encrypted transport (or simple encrypted record storage). How do you judge whether the guarantees TLS offers are "needed" or not?
  - eru 16y ago
    That judgment is partly outside the more mechanical parts of cryptography. You have to see what your application domain demands. OTR is just the first example I could think of, that gives different guarantees than most normal cryptosystems. I don't particularly recommend it for anything apart from instant messaging. And I wouldn't recommend implementing your own. If I speak to you in private (and we know each other), you can be sure you are speaking to me, but you won't be able to proof to any third party anything I said. OTR can give you something like that. PGP can't. For most application you will be well served with PGP or TLS. But be aware of what baggage they bring. For some areas losing deniability via PGP can be worse than plain text.
    - tptacek 16y ago
      This is a counterfeit argument. PGP loses "deniability" (and "forward secrecy") if by PGP you mean "the PGP user interface". But if what you mean is simply "the PGP cryptosystem" and "the PGP message format of packets and bulk encryption and signatures", then you can grant your system most any property OTR gives you. This is a moot point, because most systems would never care enough to intricately position all their features just-so to compose OTR-like features out of PGP primitives. What they need is to be able to encrypt anything without implementing trivially exploitable crypto vulnerabilities that were discovered and solved decades ago. This is a textbook case of everyone's good being strangled by someone's opinion of the perfect.

alnayyir 16y ago

>(not that I know anything about crypto) Me either, and while I chuckled, I think cperciva is one of the better qualified people to be implementing crypto.

djcapelis 16y ago
No one is qualified to implement crypto without review. cperciva is extremely qualified to implement crypto, but not without review. I think it is wise that he has implemented a bug bounty procedure. He should make sure it applies to unreleased versions too so maybe someone will put an RSS feed of his SCM checkins into their RSS reader and try and catch bugs as he's making them. :) It would be nice if he had the money to spring for paying someone else to look at all his changes, but alas... that stuff is expensive!
- tptacek 16y ago
  Bug bounties are not reviews. No professional is going to undertake a review on spec. The demand for software security is too high; most of us have our pick of interesting projects that will pay whether we find something or not. We're not unique in that respect; top iPhone developers won't work for you on spec either, not because spec is evil, but because the economics don't work. Furthermore, you can pay $1000 for XSS bugs and random memory corruption flaws in browsers because fuzzers can find them, because they're luck-of-the-draw findings, and because people are hammering those things whether you pay them or not. But $1000 doesn't pay for a day of qualified review, and no qualified reviewer would suggest less than two weeks for something like Tarsnap.
  - djcapelis 16y ago
    I agree on all of this. However, since Colin presumably doesn't want to raise his prices to pay for actual review, it is encouraging that he is at least going with bug bounties. These, at the very least, gives us a good excuse to assign them as fun things to do for graduate students with some hope that one will want to procrastinate so hard that they will actually look at the code. Also I think any reviewer who wanted to get paid would not start with Colin's code as an easy place to find bugs.