Careful. Colin Percival isn't David Wagner or Dan Boneh or even Daniel Bernstein. He wrote a paper on a side channel attack during a window of time when everyone was writing papers on microarchitectural side channel attacks, wrote a pretty cool paper on a password derivation function, and, like the authors of SSH, Tor, and DESLogin (none of them professional cryptographers), built a bunch of cryptography into a well-understood Unix networking problem.

I very much respect Colin and fully expect him to kick my ass in arguments, but, in particular, I find a good portion of his advice does not square with my professional experience; in other words: he's saying things that lay developers have already heard, and, empirically, lay developers produce very bad crypto.

It's funny you'd say that, because you're one of three-ish people on HN I weight equally with cperciva on security issues. But my explanation doesn't depend on his being one of the top 10 security guys in the world; just on his being orders of magnitude more reliable than an average Hacker News reader, like the one who I responded to.

Even that is more than required by the fundamental message I'd hoped to convey; which is "making something and sharing it can be useful; giving non-specific criticisms from a noncommitted, unassailable position is not useful." Reputation is simply bayesian evidence with which one can weight an otherwise-unsupported claim.

Separately, though, I agree that you've earned your more cynical view of the average developer. You believe Colin commits something similar to the Planning Fallacy[1] by looking at the details of a secure system and his own ability to convey the details of cryptography, instead of looking at the reference class[2] of "developers who have been taught about crypto," which in your experience still gets worse results than developers who just use ssl and gpg.

[1] http://en.wikipedia.org/wiki/Planning_fallacy [2] http://en.wikipedia.org/wiki/Reference_class_forecasting