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.
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.
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".
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.