16 ms·

Isn't the whole point of end-to-end encryption -- not to have to trust any third party -- undermined by secret source? If one does not trust Zoom not to snoop

Isn't the whole point of end-to-end encryption -- not to have to trust any third party -- undermined by secret source? If one does not trust Zoom not to snoop on content passing unencrypted through their servers, why should one trust them to provide true end-to-end encryption? And, if one does trust them to provide true end-to-end encryption, why might one not as well trust them not to snoop on unencrypted content?

sonicggg 6y ago
They are not opening their source code, as far as I know, so who is auditing this supposed end-to-end encryption?
- oscargrouch 6y ago
  Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data? The middle-man shares a temporary key where his end-point can decrypt the message at any time, generating a new key to deliver the message to its original destiny. I mean, i've always understood e2e encryption with centralized points of distributions as whatsapp, having the understanding that they, and they only, could still claim e2e while at the same time being able to decrypt the messages themselves. So i never trust the claim of full secrecy unless i know its e2e over a real p2p channel without a middle-man working as a broker between the parties (where the broken can generate and distribute the keys) Its looks like snake oil to me. Of course far from the eyes of north korea, who is barely a treat to anyone, but with all we know about things like PRISM, probably being available to all the north-american agencies.
  - nulbyte 6y ago
    > Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data? No; this is specifically what end-to-end encryption is designed to prevent. In E2E, the data is encrypted at one end and it is not decrypted until it reaches the other end, because no one in the middle has the decryption key.
    - oscargrouch 6y ago
      The middle-man in this case is a trusted one, the owner of the centralized infrastructure, not like in MITM. Isnt possible that one peer encrypt, pass it to the central server who have the other key, the central server than encrypts again and share it with the real end making it believe the key he is using actually is the same one generated in the first part of the process? Its like the OR from tor but with 3 parties instead. How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?
      - zertrin 6y ago
        Yeah in E2EE key distribution is always the tricky part. For "good" UX, usually it is based on trust that the peer keys are exchanged with help of the centralised service as middle man but that it does not alter the keys. For good security, each party should ideally check public key fingerprints with each other party via another mean of communication to ensure that there was no man in the middle. But that's poor UX and might be unpractical for large meetings of participants that do not know each other.
      - Thorrez 6y ago
        > How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything? From the article: > Participants will also see the meeting leader’s security code that they can use to verify the secure connection. The host can read this code out loud, and all participants can check that their clients display the same code. Obviously the vast majority of people won't do this, so the vast majority of people won't be fully protected against active MITMs. But the potential of meeting participants doing this will discourage attackers in many cases.
hunter2_ 6y ago
I agree. But I suppose it does have a slight benefit that if you trust the individuals at Zoom who implemented the encryption, now you no longer need to also trust the individuals at Zoom who have access to network traffic and/or server-side code but not client application code. This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.
- rsa25519 6y ago
  Didn't Zoom hire Keybase to do their encryption? > This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though. Well, before we had to trust simply that people with networking access were non-malicious. Now, we can simply trust that at least one of [crypto, network] people are non-malicious. That seems like an improvement to me.
  - kelnos 6y ago
    For me, hiring the Keybase team did not increase my trust in Zoom; it sadly lowered my opinion of the Keybase team (which had already taken a hit due to their integration of cryptocurrency into the Keybase platform).
lacker 6y ago
The point of end-to-end encryption is to prevent a government from being able to access your communications afterwards. Zoom or any other private company is much more able to implement a standard technical solution like end-to-end encryption than to resist legal subpoenas for information they have but would prefer to not have.
- desilentio 6y ago
  Are you saying that Zoom is recording conversations?
  - Spooky23 6y ago
    Zoom offers a service to record meetings in the cloud, as almost all providers do. So they can intercept, and can probably be compelled to do so by court order. E2E is something nerds complain about.
    - scubbo 6y ago
      I'll be the first to admit that I am very far from a crypto expert, but - does this implication necessary follow? Couldn't they just be recording and persisting the (encrypted) stream, and then making it available to "someone who has the key"?
      - mrstubbs 6y ago
        The Zoom backend serves as a router for (possibly hundreds) individual encrypted streams of audio and video during a meeting. In order to support a cloud-save feature, they must first decrypt those streams in order to re-encode them into a unified multimedia file. Even if they were to store encrypted versions of all of these individual audio/video streams, how would they ultimately present that back to the user on request? There is no practical or easy way to do this.
        Thorrez 6y ago

sonicggg 6y ago

They are not opening their source code, as far as I know, so who is auditing this supposed end-to-end encryption?

oscargrouch 6y ago
Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data? The middle-man shares a temporary key where his end-point can decrypt the message at any time, generating a new key to deliver the message to its original destiny. I mean, i've always understood e2e encryption with centralized points of distributions as whatsapp, having the understanding that they, and they only, could still claim e2e while at the same time being able to decrypt the messages themselves. So i never trust the claim of full secrecy unless i know its e2e over a real p2p channel without a middle-man working as a broker between the parties (where the broken can generate and distribute the keys) Its looks like snake oil to me. Of course far from the eyes of north korea, who is barely a treat to anyone, but with all we know about things like PRISM, probably being available to all the north-american agencies.
- nulbyte 6y ago
  > Not a crypto expert, but isnt possible to remain e2e and yet giving you have a central middle-man, that this middle-man have access to all the unencrypted data? No; this is specifically what end-to-end encryption is designed to prevent. In E2E, the data is encrypted at one end and it is not decrypted until it reaches the other end, because no one in the middle has the decryption key.
  - oscargrouch 6y ago
    The middle-man in this case is a trusted one, the owner of the centralized infrastructure, not like in MITM. Isnt possible that one peer encrypt, pass it to the central server who have the other key, the central server than encrypts again and share it with the real end making it believe the key he is using actually is the same one generated in the first part of the process? Its like the OR from tor but with 3 parties instead. How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything?
    - zertrin 6y ago
      Yeah in E2EE key distribution is always the tricky part. For "good" UX, usually it is based on trust that the peer keys are exchanged with help of the centralised service as middle man but that it does not alter the keys. For good security, each party should ideally check public key fingerprints with each other party via another mean of communication to ensure that there was no man in the middle. But that's poor UX and might be unpractical for large meetings of participants that do not know each other.
    - Thorrez 6y ago
      > How the receiving party can be sure the key was not switched by the all-mighty middle man who can control everything? From the article: > Participants will also see the meeting leader’s security code that they can use to verify the secure connection. The host can read this code out loud, and all participants can check that their clients display the same code. Obviously the vast majority of people won't do this, so the vast majority of people won't be fully protected against active MITMs. But the potential of meeting participants doing this will discourage attackers in many cases.

hunter2_ 6y ago

I agree. But I suppose it does have a slight benefit that if you trust the individuals at Zoom who implemented the encryption, now you no longer need to also trust the individuals at Zoom who have access to network traffic and/or server-side code but not client application code. This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though.

rsa25519 6y ago
Didn't Zoom hire Keybase to do their encryption? > This slight benefit is fairly silly, because we have no reason to give greater credibility (regarding ethics) to one set over another. At least it's a smaller set, though. Well, before we had to trust simply that people with networking access were non-malicious. Now, we can simply trust that at least one of [crypto, network] people are non-malicious. That seems like an improvement to me.
- kelnos 6y ago
  For me, hiring the Keybase team did not increase my trust in Zoom; it sadly lowered my opinion of the Keybase team (which had already taken a hit due to their integration of cryptocurrency into the Keybase platform).

lacker 6y ago

The point of end-to-end encryption is to prevent a government from being able to access your communications afterwards. Zoom or any other private company is much more able to implement a standard technical solution like end-to-end encryption than to resist legal subpoenas for information they have but would prefer to not have.

desilentio 6y ago
Are you saying that Zoom is recording conversations?
- Spooky23 6y ago
  Zoom offers a service to record meetings in the cloud, as almost all providers do. So they can intercept, and can probably be compelled to do so by court order. E2E is something nerds complain about.
  - scubbo 6y ago
    I'll be the first to admit that I am very far from a crypto expert, but - does this implication necessary follow? Couldn't they just be recording and persisting the (encrypted) stream, and then making it available to "someone who has the key"?
    - mrstubbs 6y ago
      The Zoom backend serves as a router for (possibly hundreds) individual encrypted streams of audio and video during a meeting. In order to support a cloud-save feature, they must first decrypt those streams in order to re-encode them into a unified multimedia file. Even if they were to store encrypted versions of all of these individual audio/video streams, how would they ultimately present that back to the user on request? There is no practical or easy way to do this.
      - Thorrez 6y ago