I think that second sentence is somewhat wrongheaded. Crypto bugs aren't like normal bugs. Thousands of eyes aren't likely to surface them. Open source does not have a particularly excellent track record with exposing crypto flaws.
Simultaneously, we routinely find crypto flaws on black-box reviews of commercial products, sometimes even in firmware and hardware settings.
To my eyes, it's not the availability of source code that smokes out flaws like this, it's simply the incentive structure. Colin's project gets the attention of someone like Taylor Campbell, but Colin has made a name for himself and for Tarsnap. Even if your project becomes popular, if you aren't shouting from the mountaintops about your use of cryptography, you may be unlikely to garner the specific kind of attention you need.
I should clarify. I'm not picking on the open source community. I'm differentiating the open source community form the private sector because the incentives are different. There are crypto guys in the private sector that can build secure crypto systems for $600/hour. Now, crypto is devilishly hard to do, so there's no guarantee their system would be secure either. But if you have nation-state levels of funding, you certainly can buy a system that would take serious talent and funding to break. On the other hand, open source communities are motivated by intrinsic incentives. Clearly this is enough to implement state-of-the-art operating systems, but is intrinsic motivation enough to implement secure crypto? It may well be that the bar is too high in this area and I think the next decade will yield some interesting results here. Even if we count OpenSSL as a point for open source (generous), that's one reasonably secure system over the course of a decade.
> I'm differentiating the open source community form the private sector because the incentives are different.
The incentive in the private sector is to maximize profit, which means minimizing costs.
> But if you have nation-state levels of funding, you certainly can buy a system that would take serious talent and funding to break.
You might be able to build such a system, or you can buy a system that just passes all acceptance tests, which is where the incentive is (since this minimizes costs). Given that testing a cryptosystem for correctness is just about impossible, what do you suppose happens?
The best assurance that I get is when I'm told which standard implementation a product uses. If a private entity without a reputation in cryptography told you that they rolled their own, would you trust them? How many crytographers would you trust? I know whom I would, and I don't even need a full hand to count them.
Colin Percival told you that he uses RSA-2048, AES-256 in CTR mode, and HMAC-SHA256. None of that information helps you with a one-line implementation error that incorrectly handles CTR nonces. That's 'poet's point.
By "standard implementation", I mean something like "OpenSSL 0.9.8o". This helps me more, since I can be fairly certain that >0 experts have reviewed that code. Given that absolute verification is just about impossible, it's a question of reducing the probability of failure wherever possible. With a private, closed implementation, the number of reviewers is almost certain to be lower.
By "standard implementation", I mean something like "OpenSSL 0.9.8o". This helps me more, since I can be fairly certain that >0 experts have reviewed that code.
It's a bit more complicated than that. Yes, >0 experts have reviewed OpenSSL code. But <1 experts have reviewed all of the OpenSSL code. Did the bits which matter to you get reviewed? Who knows...
In the open source world at least others get to look at the code and find (and perhaps fix) problems.