[sdevlin]

Source code doesn't really matter as much as you'd think. In fact, it can be deceptive in some cases. I would call source code a nice-to-have.

In contrast, observing the network traffic, debugging the application, and examining the decompiled binary will tell you exactly what's going on.

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

[electic]

Telegram bashing aside, this is very wrong. It is always better to have the source code to inspect the entire package. Without the source code, there is no way to fully verify the security of a solution. For Telegram and WhatsApp, the clients and server code should be released if you want to make sure.

[smtddr]

No, you're wrong.

People can give you whatever source code they want. That doesn't meant it's the same as what's running in production. While this is tin-foil-hat paranoia, when it comes to encryption software in this post-snowden world it is definitely more reliable to reverse-engineer the binary & network traffic than to just believe the provided source-code to encryption in a popular social app. Or compile the app from source that has been verified by trusted people. Definitely not believing that a binary blob running on your hardware is the same as the provided source.

That said, it's also good to ask for source code so later on when reverse-engineering shows something different you've now caught the offending party in a lie; which is something good to have on record to refer to later on.

[electic]

> Without the source code, there is no way to fully verify the security of a solution.

So you are telling me if you had the source code you would not be able to verify the code and also use the code to fully verify the expected behavior of the binary?

[tptacek]

It is not as easy to verify source code as it sounds.

[electic]

and it is not easy to do black box testing either.

[wglb]

this is very wrong: No, it is quite correct. It is slightly more convenient to have the source code, But then again, it can be misleading, as you don't know if that source code is actually corresponding to the binary that is actually executing.

[thanksgiving]

Open sourcing/Making available for inspection the source code of an application is not enough if the herd just uses the pre built binaries instead of compiling it themselves. Perhaps we can someday have free and open source software with reproducible builds[0]?

[0] https://wiki.debian.org/ReproducibleBuilds