Honest question for those in the know: If I wanted to run my own personal “analysis” to verify the security of Signal, where would I start? Is it even possible? Just curious if there was a way to “know” rather than “trust”.
Related question, is there an endorsement from a recognised expert? I'd have to live with that since I won't be getting an advanced degree in cryptography.
Heh, I'd never even looked at the website. The four people they have there seem good enough for me. At least Schneier, Green, and tptacek seem to be technical enough, and the others will have big enough need to have done the due diligence properly.
There's a lot more than just crypto. Its much more common for systems to fail in the supporting code then it is for the crypto to be wrong. So first step is probably learn reverse engineering and verify the crypto is being used correctly.
Unless the build is reproducible it would be smart for a paranoid person to use the published source code only as a comparison with the decompiled app.
Certainly not required. A PhD will teach you a lot about methodology but not necessarily the technical details required and involved in secure multi-party or P2P messaging.
How do you know that the binary you run actually corresponds to the source code you read?
EDIT: and would you then also review every commit to make sure nothing bad gets introduced? No, at some point you have to place trust in the vendor, the developers, independent audits, etc.
We're making great strides into software being completely deterministic. The Bitcoin project for many years has had completely deterministic binaries and a ceremony process for GPG signing the output with many individual parties.
How do you know the compiler actually compiles the source code to the binary you expect without injecting backdoors? How do you know that the hardware actually follows the instructions in the binary as they are specified?
How do you know you're not living in a computer simulation in which the operators can access your data without any backdoors whatsoever?
Cartesian doubt becomes pointless at some point. If you're worried that the deep state has implanted microchips in your brain to prevent you from analyzing signal, it probably doesn't matter because at that point they wouldn't need to hack signal to get to you.
A less snarky and more realistic answer is: threat models and risk assesment. (Non-divine) adversaries generally have limited resources. The limit may be high, but its still there. You can realistically worry about a government coercing a service to hand over keys, because that's easily within their power. On the other hand, having a giant conspiracy-trusting trust style-where every compiler & microchip has a backdoor that is inserted into every tool ever compiled, is a bit unrealistic. It would take thousands of people to be in on it to pull it off, spread across many countries (who hate each other) over at least 50 years. Having that many people, especially academics, keep that type of secret for that long is basically impossible. If they could do that, it would be child's play to have most of the protestors be gov agents, so if you think this is realistic, worry about that first. Anyways, in my judgement governments don't have that kind of power, so its probably not something to worry about.
So, to conclude, estimate the level of power and influence you think your enemies have, and then take steps to rule out the possibilities that your enemies have done the things that are theoretically in their power to do. Start with the possibilities that are most likely multiplied by how bad it would be for you (liklihood*severity = risk)
That's my point, you can't establish trust by checking everything yourself. So you delegate to other things as an approximation. In this case, Signal seems to be reputable, have competent developers and afaik no history of leaks or malevolence so I would rely on that rather than a half-assed source code review.
You can build the source locally, then compare the MD5 hash value of your build to (1) the hash value they post publicly for their build and (2) the actual hash value of their build once you download it.
Assuming all three match, you know that the binary matches the source.
Someone who is more technically inclined can probably go into more detail on this.
This is actually more involved than it sounds. It is pretty easy for the compiler to introduce nondeterminism and result in slightly different binaries. I know this for a fact because I fixed a couple bugs like this in LLVM.
For the curious: we actually were intentional about finding these, by compiling many programs with the same parameters on different machines. One with a 32 bit OS and toolchain, the other one on a 64 bit machine, and we would get alerted when we produced binaries with a different checksum.
MD5 is not safe for this use case. Assuming the provider is malicious, this is exactly the scenario where MD5 is broken (i.e. it is possible to make source code that compiles a certain way so that you can make another binary that has the same hash but is different. The bright side is the attack would have evidence as there would be certain patterns in the binary that could be detected if you knew how/where to look. That said, just use sha256)
I never realized signal code was available open source... so in theory one could “build” then load the software via developer tools (assuming you have an iOS dev account).
