3 ms·

> after all, Colin circulates the code to Tarsnap so people can find exactly these kinds of bugs. Unfortunately, the population of people who can spot bugs like

by doe88 13y ago

> after all, Colin circulates the code to Tarsnap so people can find exactly these kinds of bugs. Unfortunately, the population of people who can spot bugs like this in 2010's-era crypto code is very limited, because, again, people don't learn how to implement attacks. I disagree, I think there is so much code, including so much crypto code out there in open source projects that you either have to wait for someone explicitely reviewing this code or someone particularly interessed in this project to find it. Otherwise on your other points, I don't disagree with your argument but I think it's more important in that order to 1- know the mathematical aspects behind what you implement 2- know how to implement crypto (by having studied different open source projects) 3- know all the main attacks at code level. Ideally one should have a good knowledge on these 3 points before feeling confident in his code.

tptacek 13y ago
Learning how to implement crypto by studying open source projects is a recipe for getting people's sites plastered across Pastebin. It is exactly this 1-2-3 approach to learning that I was thinking about when I wrote the fateful tweet. How do you evaluate whether software is making proper choices? Why do you assume popular open source packages are secure? They often aren't; in fact, they're broken in meaningful ways more often than not. It's the engineering equivalent of a game of telephone; you copy the errors of the systems you crib from, which are multifarious, and at the same time introduce new ones because human nature has you working hard only so long as there's a payoff, and 99.999% of the payoff in this approach happens once your system round-trips properly; you miss all the subtleties that happen after round-tripping works. So yeah, don't do it like this.
- doe88 13y ago
  Yeah that's always your mantra, I'm glad for you that you inherited your skills from god and think nobody else is able to dicern good code from bad code, well implemented crypto, from badly implemented crypto. But I dare to say that for instance it doesn't require to be a genius to know the quality of DJB's code and only by studying how it is implemented I think you'll agree with me that it's possible to learn a lot. In this day and age there are several open source projects with a good code quality I think. And I don't assume anything on open source projects I only say that knowing who wrote them I know I can expect an overall good quality, but even in this case you still can keep a critical eye. For instance I don't know much on pairings, so the first thing I would do after reading the theory, I would try to find a decent library implementing it, just to learn a bit more, it does not engage to anything.
  - tptacek 13y ago
    Let me put it this way: the approach you've outlined is neither Colin's nor mine. If you want to learn by writing proofs for every single aspect of your system, go ahead. Neither Colin nor I were suggesting that you could hope to learn how to build secure cryptography by cribbing code from open source projects. Colin isn't just saying "understand the math"; he's saying, "build provable systems, then prove them".

by doe88 13y ago

tptacek 13y ago

Learning how to implement crypto by studying open source projects is a recipe for getting people's sites plastered across Pastebin. It is exactly this 1-2-3 approach to learning that I was thinking about when I wrote the fateful tweet. How do you evaluate whether software is making proper choices? Why do you assume popular open source packages are secure? They often aren't; in fact, they're broken in meaningful ways more often than not. It's the engineering equivalent of a game of telephone; you copy the errors of the systems you crib from, which are multifarious, and at the same time introduce new ones because human nature has you working hard only so long as there's a payoff, and 99.999% of the payoff in this approach happens once your system round-trips properly; you miss all the subtleties that happen after round-tripping works. So yeah, don't do it like this.

doe88 13y ago
Yeah that's always your mantra, I'm glad for you that you inherited your skills from god and think nobody else is able to dicern good code from bad code, well implemented crypto, from badly implemented crypto. But I dare to say that for instance it doesn't require to be a genius to know the quality of DJB's code and only by studying how it is implemented I think you'll agree with me that it's possible to learn a lot. In this day and age there are several open source projects with a good code quality I think. And I don't assume anything on open source projects I only say that knowing who wrote them I know I can expect an overall good quality, but even in this case you still can keep a critical eye. For instance I don't know much on pairings, so the first thing I would do after reading the theory, I would try to find a decent library implementing it, just to learn a bit more, it does not engage to anything.
- tptacek 13y ago
  Let me put it this way: the approach you've outlined is neither Colin's nor mine. If you want to learn by writing proofs for every single aspect of your system, go ahead. Neither Colin nor I were suggesting that you could hope to learn how to build secure cryptography by cribbing code from open source projects. Colin isn't just saying "understand the math"; he's saying, "build provable systems, then prove them".