4 ms·

I would argue that the "distributed by the same entity which it purports to secure against" is a less relevant distinction than this makes it out to be. Consid

by ryan-c 3y ago

I would argue that the "distributed by the same entity which it purports to secure against" is a less relevant distinction than this makes it out to be. Consider, for example, Signal's progenitor, TextSecure, or E2EE for RCS. What's stopping a government from compelling these services to ship backdoored code and then compelling the telco to spill the now-vulnerable ciphertext — which doesn't also stop them from doing the same to modern Signal? I would also argue that the FBI/Apple example is exactly that scenario — the code being distributed by a different entity (Apple) from which it purports to secure against (any party with physical access).

hlandau 3y ago
Author here. I think the problem is the notion of services shipping code. If you get the endpoint software from a different entity to the communications provider, that's the first step to fixing this. XMPP+OMEMO etc. would be examples of this kind of arrangement, whereas Whatsapp/Signal actually ban the use of third party clients. Once you have this, this means there now two nodes which need to be coerced to compromise the system - endpoint software provider and communications provider. Well, actually, just one - the endpoint software could just be changed to use a different, compromised communications provider (I think you were envisaging some more subtle compromise of ciphertext above). This can be fixed, however. A lot of the work Linux distros have done around reproducible builds, and the new focus on release transparency, is informative here. You could absolutely have a FOSS project with a release process that requires multiparty signatures of releases with the release signers in different jurisdictions, and requiring proof of logging to a release transparency log, etc. I suspect a lot of pushback on this is because the implications are significant, Emperor's New Clothes and all, but fixing this sort of thing is the first step to solving the problem. Pretty much the entire internet community was in a mindset of "but government wouldn't ever do..." complacency before Snowden, despite increasingly blatant warning signs, before people were forced to accept that reality. (The reason is simple; it's a funny thing about humans, when they realise some fact X being true would be very materially inconvenient to them, their first reaction is to argue that X isn't true, as though reality is negotiable...) Having an accurate view of just how impaired our security model is in this area is the first step to making things better IMO.
- littlestymaar 3y ago
  > Well, actually, just one - the endpoint software could just be changed That's exactly what makes your entire argument silly: when you use a piece of software, you're trusting this piece of software, and there's no way around this, being web-based doesn't change a damn thing compared to any other software with automatic update.
- ryan-c 3y ago
  I think, to a large extent, this is a question of threat models. You're absolutely right that a lot of E2EE is fundamentally a "circle of protection against law", but that doesn't mean it isn't useful. The protection varies a lot depending on which law (jurisdiction) the threat has, after all. Against a government entity, communications providers (telcos) can be considered already compromised, and represent approximately zero marginal resistance. Even reproducible builds and audits only raise the bar, they can't solve the problem completely. I'm sure other comments are bringing up reflections on trusting trust, and the underhanded crypto contest has run a few times (I was a finalist). I suppose my point is that security in real-world systems is never absolute, and always involves trade offs. Our goal should be to have better trade offs.
  - ryan-c 3y ago
    What if certificate transparency but for app distributed via app stores?

by ryan-c 3y ago

hlandau 3y ago

Author here. I think the problem is the notion of services shipping code. If you get the endpoint software from a different entity to the communications provider, that's the first step to fixing this. XMPP+OMEMO etc. would be examples of this kind of arrangement, whereas Whatsapp/Signal actually ban the use of third party clients. Once you have this, this means there now two nodes which need to be coerced to compromise the system - endpoint software provider and communications provider. Well, actually, just one - the endpoint software could just be changed to use a different, compromised communications provider (I think you were envisaging some more subtle compromise of ciphertext above). This can be fixed, however. A lot of the work Linux distros have done around reproducible builds, and the new focus on release transparency, is informative here. You could absolutely have a FOSS project with a release process that requires multiparty signatures of releases with the release signers in different jurisdictions, and requiring proof of logging to a release transparency log, etc. I suspect a lot of pushback on this is because the implications are significant, Emperor's New Clothes and all, but fixing this sort of thing is the first step to solving the problem. Pretty much the entire internet community was in a mindset of "but government wouldn't ever do..." complacency before Snowden, despite increasingly blatant warning signs, before people were forced to accept that reality. (The reason is simple; it's a funny thing about humans, when they realise some fact X being true would be very materially inconvenient to them, their first reaction is to argue that X isn't true, as though reality is negotiable...) Having an accurate view of just how impaired our security model is in this area is the first step to making things better IMO.

littlestymaar 3y ago
> Well, actually, just one - the endpoint software could just be changed That's exactly what makes your entire argument silly: when you use a piece of software, you're trusting this piece of software, and there's no way around this, being web-based doesn't change a damn thing compared to any other software with automatic update.
ryan-c 3y ago
I think, to a large extent, this is a question of threat models. You're absolutely right that a lot of E2EE is fundamentally a "circle of protection against law", but that doesn't mean it isn't useful. The protection varies a lot depending on which law (jurisdiction) the threat has, after all. Against a government entity, communications providers (telcos) can be considered already compromised, and represent approximately zero marginal resistance. Even reproducible builds and audits only raise the bar, they can't solve the problem completely. I'm sure other comments are bringing up reflections on trusting trust, and the underhanded crypto contest has run a few times (I was a finalist). I suppose my point is that security in real-world systems is never absolute, and always involves trade offs. Our goal should be to have better trade offs.
- ryan-c 3y ago
  What if certificate transparency but for app distributed via app stores?