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