5 ms·
with closed source, hosted software E2EE is as much about trust as it is about technology since you can't verify its implementation. arguably, if trust is there
by gfodor 6y ago
with closed source, hosted software E2EE is as much about trust as it is about technology since you can't verify its implementation. arguably, if trust is there, E2EE doesn't get you much anyway other than for scenarios where the company itself is breached.
in any case, if the trust isn't there, you can't validate the E2EE, so your risk profile with regards to using the software doesn't change much.
- m3kw9 6y agoApple FaceTime is also closed source, E2E and verifiable
- dane-pgp 6y agoWhat is the process for verifying that FaceTime isn't leaking the encryption keys to Apple's servers?
- m3kw9 6y agoI don’t know, but as a black box it’s been extensively looked at. But nothing is unhackable even E2E.
- Fice 6y agoHow would one know that this black box works the same for every user? What would stop Apple from distributing a compromised update to everyone or to selected users?
- m3kw9 6y agoYep any protocol and any app can have this problem.
- dane-pgp 6y agoThe protection against this problem is to have the app (or the platform it's running on) check before installing an update that the hash of the binary it has downloaded has been recorded in a public transparency log. With closed source software, though, this doesn't give as much confidence, since a company could create a version which they send to everyone but which contains an "if (userId == NSA_TARGET)" conditional branch.
- SahAssar 6y agoYou can verify closed source E2EE as long as you can inspect the traffic going client-server. The problem is that most E2EE apps allow auto-updating, so baking in something that transmits info to a third party is easy (but detectable with enough eyes on the code).
- gfodor 6y agoBut what's stopping the software from, say, having a backdoor that is only exposed under certain conditions? For example, if you are under an FBI investigation. I suppose you could automate the verification on a per-call basis. Unfortunately, every bit over the wire would need to be seen by a fool-proof algorithm to ensure your safety. Seems not tractable.
- SahAssar 6y agoAgreed. You can only verify E2EE for the traffic you inspect, not for traffic you don't. If they open-sourced the client it'd help a lot, but I'd also like to point out that you probably have stuff in your current device that has DMA and network access that is not open source either (PSP, IME, 4G modem, and so on) and that could break that encryption too. If you are under serious investigation I wouldn't trust anything "smart" manufactured in a country under that investigations jurisdiction.
- gfodor 6y agoYup fair point. Circling back to Zoom, I think the trust part of this has been violated enough that such an inspector tool ought to be considered strictly necessary to use it if you are security minded. So in the end, there's not much of a point to the announcement imo.
- dane-pgp 6y agoIf the closed source E2EE app is sending encrypted messages but leaking bits of the key in how those messages are padded, for example, how would you detect that? As for the threat model of open source E2EE apps auto-updating to an insecure version, you're right that this needs some extra defences. One way would be to use a binary-transparency log[0] to make sure that the open source project had publicly committed to a specific binary at least 24 hours in advance of pushing the auto-update. This system relies on there being auditors out there who would raise the alarm if a malicious update was released, or a hash was included in the log for which there was no corresponding (reproducibly buildable) source code. [0] https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency