[huhtenberg]

The thing is however that any cryptosystem can be trivially compromised by making its PRNG predictable.

This cannot be caught by observing the network traffic and it is really hard to catch by reversing or tracing the binary. Especially if the compromise is not an outright srand(0), but an algorithmic weakness. Then, even if it is found, then it's virtually impossible to determine whether it was benign or deliberate. Now further consider the implications if an app uses a 3rd party PRNG such as those supplied by the operating system or the hardware or if it gets its PRNG seed data from an inherently untrusted sources (such as the OS).

I mean ... the source code being open is obviously irrelevant to the security of a pre-built binary and the adherence to the open specs is not much of an assurance either, because of the PRNG angle. In practical terms it really means that you have to have trust in a product vendor. Period. Because there is always a way for them to screw you over and to get away with it.

[sdevlin]

All of these points are orthogonal as to whether source code is required for a security audit.

[tptacek]

Weaknesses in random number generation are arguably easier to spot in instrumented binaries and dynamic analysis than they are with static analysis. Auditing an RNG from source involves enough mental modeling to trace random numbers and track the state of whatever generator provided them.