Tor Messenger 0.1.0b5 is released

> I think it's difficult to use SSSS to keep the signing key distributed. At some point someone has to reassemble the signing key on some computer to sign the release, and then we have a single person with a copy of the signing key, which is no longer distributed.

Point taken. Perhaps SSSS used *in isolation* is really more suitable for a Board of Trustees which wishes to be able to reconstruct a copy of the master key to the company networks in case their cybersecurity chief "breaks bad" (c.f. the experience of San Francisco some years ago).

> What we can do however is having the build signed by multiple people. We do it for Tor Browser. We should do it for Tor Messenger too, but first we need to have the builds for all platforms reproducible (currently only the Linux builds are, so the sha256sums.txt files which contains builds for all platforms wouldn't be matching).
>
> But the signature of official builders is not all. We also hope that other people that we don't know will verify our builds anonymously, and say something if something seems wrong

I think Open Source community must consider every available technical tool, legal strategm, geolocational distribution, to come up with a workable solution to the threat from "rubber hose" breakage of the authentication and data integrity functions of cryptography.

It worries me, boklm, that no-one at Tor Project has yet clearly stated that they even understand the nature of this threat. If that's true, there is no way you can prepare defenses against it. That's terrible because I believe you may have only weeks or months before you (and some or all of your users) fall victim to coerced cooperation by

o key Tor Project people in abusing cryptographic signing keys to sign maliciously modified TP products (TB, TM, tor client, tor server software) provided by the bad guys,

o key certificate authority people is abusing signing keys by signing bad certs produced by the bad guys.

Here is that link again:

http://arstechnica.co.uk/security/2016/02/most-software-already-has-a-g…
Most software already has a “golden key” backdoor—it’s called auto update
Software updates are just another term for cryptographic single-points-of-failure.
Leif Ryge
27 Feb 2016

> No, you were clear. I just think that reproducible builds solve the same problem.

I don't think that's true. If I'm wrong you need to explain this:

> Ideally, before Sukhbir signs each build, auditors will reproduce it and compare hashes. If they don't match, they'll blow the whistle.

Here is how Leif Ryge (I think some Tor people know him) described the threat:

http://arstechnica.co.uk/security/2016/02/most-software-already-has-a-g…
Most software already has a “golden key” backdoor—it’s called auto update
Software updates are just another term for cryptographic single-points-of-failure.
Leif Ryge
27 Feb 2016

> Q: What does almost every piece of software with an update mechanism, including every popular operating system, have in common?
>
> A: Secure golden keys, cryptographic single-points-of-failure which can be used to enable total system compromise via targeted malicious software updates.
>
> I'll define those terms: By "malicious software update," I mean that someone tricks your computer into installing an inauthentic version of some software which causes your computer to do things you don't want it to do. A "targeted malicious software update" means that only the attacker's intended target(s) will receive the update, which greatly decreases the likelihood of anyone ever noticing it. To perform a targeted malicious software update, an attacker needs two things: (1) to be in a position to supply the update and (2) to be able to convince the victim's existing software that the malicious update is authentic. Finally, by "total system compromise" I mean that the attacker obtains all of the authority held by the program they're impersonating an update to. In the case of an operating system, this means that the attacker can subvert any application on that computer and obtain any encryption keys or other unencrypted data that the application has access to.
>
> A backdoored encryption system which allows attackers to decrypt arbitrary data that their targets have encrypted is a significantly different kind of capability than a backdoor which allows attackers to run arbitrary software on their targets' computers. I think many informed people discussing The Washington Post's request for a "secure golden key" assumed they were talking about the former type of backdoor, though it isn't clear to me if the editorial's authors actually understand the difference.
> ...
> Many software projects have only begun attempting to verify the authenticity of their updates in recent years. But even among projects that have been trying to do it for decades, most still have single points of devastating failure.
>
> In some systems there are a number of keys where if any one of them is compromised such an attack becomes possible. In other cases it might be that signatures from two or even three keys are necessary, but when those keys are all controlled by the same company (or perhaps even the same person) the system still has single points of failure.
>
> This problem exists in almost every update system in wide use today. Even my favorite operating system, Debian, has this problem.
>
> [Software developers] probably thought they would be able keep the keys safe against realistic attacks, and they didn't consider the possibility that their governments would actually compel them to use their keys to sign malicious updates.
>
> Fortunately, there is some good news. The FBI is presently demonstrating that this was never a good assumption, which finally means that the people who have been saying for a long time that we need to remove these single points of failure can't be dismissed as unreasonably paranoid anymore.

Here is one possible scenario:

FBI serves Tor Project with an NSL (which is automatically accompanied by a gag order forbidding recipients from telling anyone about the secret order, on pain of very lengthy prison terms) or some court order (accompanied with a "delayed notification" which can be renewed every 90 days simply by FBI asking for a renewal) ordering developers to use their authentic signing key(s) to sign a version of latest TM or TB tarball which has been provided by FBI, and which contains hidden malware. Facing indefinite imprisonment or worse--- perhaps they are sitting in jail and told they will remain there unless they agree to cooperate--- the developers sign the maliciously modified tarball. That's "rubber hose" breakage of the *authentication* function of gpg.

With NSA help, FBI then manages to divert https connections by targeted Tor users attempting to download the next edition of TB or TB tarball to their own site, where they are served the trojaned version of the tarball. Perhaps NSA has compelled the Certificate Authority to use *their* genuine signing key to validate FBI's fake torproject.org PEM certificate, thus fooling users into thinking they are connected to the genuine website.

Since the detached signature verifies against the genuine signing key, the targeted users accept the "updated" as genuine.

Meanwhile, the "verifiers" you describe get the genuine tarball like almost everyone else, and thus fail to detect the targeted attack, and because of the gag order they have no way of knowing you were forced to sign malware with your authentic key.

Another scenario: FBI not only compels you to use your authentic key to sign maliciously modified tarballs, they secretly seize the domain torproject.org and serve the bad tarballs to *everyone* (no bad PEM needed).

Maybe I misunderstood what you said, but I am not sure the verifiers would catch the deception in this case either, because FBI has complete control over your persons and your domain, so they can manipulate all your communications with the verifiers.