3 ms·

You 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

You 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 ago
But 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 ago
  Agreed. 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 ago
    Yup 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 ago
If 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
g-b-r 6y ago
I imagine you mean inspecting everything that gets transmitted besides the -2E part, but even if you could there are a thousand ways for not-really-safely-encrypting a communication without you being able to notice

gfodor 6y ago

But 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 ago
Agreed. 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 ago
  Yup 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 ago

If 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

g-b-r 6y ago

I imagine you mean inspecting everything that gets transmitted besides the -2E part, but even if you could there are a thousand ways for not-really-safely-encrypting a communication without you being able to notice