7 ms·

It's encrypted all the way from one end to the other end, we just also happen to have a copy of the key and can dencrypt it in the middle. Technically, the exa

by bisby 6y ago

It's encrypted all the way from one end to the other end, we just also happen to have a copy of the key and can dencrypt it in the middle. Technically, the exact packets of the data you send is E2E encrypted... but the copies they make for themselves aren't.

paulryanrogers 6y ago
Is that consistent with the traditional definition of E2E? And if so then what's the term for encryption that a middle man cannot decrypt?
- tcoff91 6y ago
  It’s definitely not adhering to the definition of E2E encryption. However given Zoom’s history of shadiness it’s a pretty good guess about how it will be implemented.
- pwdisswordfish2 6y ago
  Regarding question #2, Peer-to-peer.
  - g-b-r 6y ago
    If that's the answer to "what's the term for encryption that a middle man cannot decrypt", NO: peer-to-peer simply means... well, pretty much it means sending IP packets directly to each other rather than through a central server (yes, not much of a thing, but it meant you could get free music more easily, so the term got a lot of traction)
    - pwdisswordfish2 6y ago
      That's right. It is certainly possible to use peer-to-peer to send unencrypted packets. Peer-to-peer does not imply encryption. It does imply avoiding a "middleman". Thus, to send encrypted packets without using a middleman, peer-to-peer is a viable method.
      - g-b-r 6y ago
        > It does imply avoiding a "middleman" No, it only implies avoiding a central server (and not even for every aspect of the service), you still run through routers, ISPs, NSA etc. If you are certain that there's no middleman, you don't need encryption. N.B. Maybe someone defines it in another way today, but when the term became popular, with Napster, it really meant simply not having a central server for certain functions, or even more banally not downloading your mp3s from a web site or ftp server; it did have some significance also because the legal aspect of it was more uncertain; when people started getting 100k dollars fines, peer-to-peer stopped meaning much, sometimes it's better to send packets directly to each other, other times through a server, but you almost always encrypt and almost always ought to encrypt end-to-end
        pwdisswordfish2 6y ago
        The central server is the "middleman" as I am using that term. Routers are not middlemen under the meaning I am using. I am referring to peer-to-peer without any supernode forwarding traffic. No central server. There may be a "rendezvous server" involved in allowing two nodes to discover how to connect to one another, however that server does not route traffic. I never implied a need for encryption associated with peer-to-peer. The parent comment asked about avoiding a middleman. I have no idea what "end-to-end encryption" means, nor do I seek to know. I do not wish to be part of that debate. The record of how that term is being applied speaks for itself. I do know of the term "end-to-end" as in https://en.wikipedia.org/wiki/End_to_end_principle https://en.wikipedia.org/wiki/End_to_end_principle One can find this concept in many of the early RFCs. To me, "peer-to-peer" (with no central server) is in the spirit of end-to-end. This is why for example, people will sometimes say, "The internet was originally peer-to-peer."
        g-b-r 6y ago
        I know that the term "peer-to-peer" could be interpreted in many ways, but to the best of my knowledge it is usually interpreted how I wrote above. Which I think it's pretty much how you defined it too in your (last) comment, so I'm not sure what we're debating. The important thing was that no one reading these comments get the impression that the multitude of systems that describe themselves as "peer-to-peer" are for sure using "encryption that a middle man cannot decrypt". --- > The parent comment asked about avoiding a middleman Middle man in cryptography is anyone intercepting a message --- > I have no idea what "end-to-end encryption" means, nor do I seek to know Well, I don't mean to be rude, but then there's not much you can say in a discussion about encryption... --- Look, the important thing was to underscore that the https://news.ycombinator.com/item?id=23554823 https://news.ycombinator.com/item?id=23554823 comment was (apparently) wrong, I don't have any interest in winning a battle, I appreciate your enthusiasm, you probably currently don't know everything about cryptography or networking and there's nothing wrong with that, no one is born expert and no one knows everything there is to know. I have to go to sleep, bye
- just-ok 6y ago
  > What's the term for encryption that a middle man cannot decrypt? I don't know if there's a term, but short of exchanging public keys in person there will always be a theoretical attack vector because there's always some[one|thing] in between you and your recipient.
- g-b-r 6y ago
  real encryption?
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
just-ok 6y ago
This could be the case for literally any E2EE service that controls key distribution (including WhatsApp, Signal, etc.), especially when there's no way to verify key fingerprints (here Signal differs because it does have a way, and it's open source so you can be more confident that it's not BSing you). It's shocking to me how often this is glossed over when discussing E2EE services: you still must trust the platform.
- vonquant 6y ago
  E2EE and open source: the two things people assume automatically makes things super-crazy-secure. The implementation of E2EE must be robust and there must be somebody who is actually checking the source code (plus verifiable builds)
  - just-ok 6y ago
    Don't forget the human element: users still have actually do the verifying (e.g. checking public key fingerprints of recipients) that the source code enables!
  - dkersten 6y ago
    It doesn’t automatically make everything secure, but it’s still a prerequisite for a trusted secure thing.
  - antris 6y ago
    If you go down that road, you can make this argument infinitely. Even if you verify your builds, you cannot know if the software you are using to check the build isn't compromised. Or if you check the software you use to check the build, you have to check the software doing that check and so on. Nothing makes software automatically super-crazy-secure. Absolute security doesn't exist.
    - okamiueru 6y ago
      You'd get close by doing all you mentioned, but also compiling and hosting the code and infrastructure yourself. Not often this is feasible.

by bisby 6y ago

paulryanrogers 6y ago

Is that consistent with the traditional definition of E2E? And if so then what's the term for encryption that a middle man cannot decrypt?

tcoff91 6y ago
It’s definitely not adhering to the definition of E2E encryption. However given Zoom’s history of shadiness it’s a pretty good guess about how it will be implemented.
pwdisswordfish2 6y ago
Regarding question #2, Peer-to-peer.
- g-b-r 6y ago
  If that's the answer to "what's the term for encryption that a middle man cannot decrypt", NO: peer-to-peer simply means... well, pretty much it means sending IP packets directly to each other rather than through a central server (yes, not much of a thing, but it meant you could get free music more easily, so the term got a lot of traction)
  - pwdisswordfish2 6y ago
    That's right. It is certainly possible to use peer-to-peer to send unencrypted packets. Peer-to-peer does not imply encryption. It does imply avoiding a "middleman". Thus, to send encrypted packets without using a middleman, peer-to-peer is a viable method.
    - g-b-r 6y ago
      > It does imply avoiding a "middleman" No, it only implies avoiding a central server (and not even for every aspect of the service), you still run through routers, ISPs, NSA etc. If you are certain that there's no middleman, you don't need encryption. N.B. Maybe someone defines it in another way today, but when the term became popular, with Napster, it really meant simply not having a central server for certain functions, or even more banally not downloading your mp3s from a web site or ftp server; it did have some significance also because the legal aspect of it was more uncertain; when people started getting 100k dollars fines, peer-to-peer stopped meaning much, sometimes it's better to send packets directly to each other, other times through a server, but you almost always encrypt and almost always ought to encrypt end-to-end
      - pwdisswordfish2 6y ago
        The central server is the "middleman" as I am using that term. Routers are not middlemen under the meaning I am using. I am referring to peer-to-peer without any supernode forwarding traffic. No central server. There may be a "rendezvous server" involved in allowing two nodes to discover how to connect to one another, however that server does not route traffic. I never implied a need for encryption associated with peer-to-peer. The parent comment asked about avoiding a middleman. I have no idea what "end-to-end encryption" means, nor do I seek to know. I do not wish to be part of that debate. The record of how that term is being applied speaks for itself. I do know of the term "end-to-end" as in https://en.wikipedia.org/wiki/End_to_end_principle https://en.wikipedia.org/wiki/End_to_end_principle One can find this concept in many of the early RFCs. To me, "peer-to-peer" (with no central server) is in the spirit of end-to-end. This is why for example, people will sometimes say, "The internet was originally peer-to-peer."
        g-b-r 6y ago
        I know that the term "peer-to-peer" could be interpreted in many ways, but to the best of my knowledge it is usually interpreted how I wrote above. Which I think it's pretty much how you defined it too in your (last) comment, so I'm not sure what we're debating. The important thing was that no one reading these comments get the impression that the multitude of systems that describe themselves as "peer-to-peer" are for sure using "encryption that a middle man cannot decrypt". --- > The parent comment asked about avoiding a middleman Middle man in cryptography is anyone intercepting a message --- > I have no idea what "end-to-end encryption" means, nor do I seek to know Well, I don't mean to be rude, but then there's not much you can say in a discussion about encryption... --- Look, the important thing was to underscore that the https://news.ycombinator.com/item?id=23554823 https://news.ycombinator.com/item?id=23554823 comment was (apparently) wrong, I don't have any interest in winning a battle, I appreciate your enthusiasm, you probably currently don't know everything about cryptography or networking and there's nothing wrong with that, no one is born expert and no one knows everything there is to know. I have to go to sleep, bye
just-ok 6y ago
> What's the term for encryption that a middle man cannot decrypt? I don't know if there's a term, but short of exchanging public keys in person there will always be a theoretical attack vector because there's always some[one|thing] in between you and your recipient.
g-b-r 6y ago
real encryption?

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

just-ok 6y ago

This could be the case for literally any E2EE service that controls key distribution (including WhatsApp, Signal, etc.), especially when there's no way to verify key fingerprints (here Signal differs because it does have a way, and it's open source so you can be more confident that it's not BSing you). It's shocking to me how often this is glossed over when discussing E2EE services: you still must trust the platform.

vonquant 6y ago
E2EE and open source: the two things people assume automatically makes things super-crazy-secure. The implementation of E2EE must be robust and there must be somebody who is actually checking the source code (plus verifiable builds)
- just-ok 6y ago
  Don't forget the human element: users still have actually do the verifying (e.g. checking public key fingerprints of recipients) that the source code enables!
- dkersten 6y ago
  It doesn’t automatically make everything secure, but it’s still a prerequisite for a trusted secure thing.
- antris 6y ago
  If you go down that road, you can make this argument infinitely. Even if you verify your builds, you cannot know if the software you are using to check the build isn't compromised. Or if you check the software you use to check the build, you have to check the software doing that check and so on. Nothing makes software automatically super-crazy-secure. Absolute security doesn't exist.
  - okamiueru 6y ago
    You'd get close by doing all you mentioned, but also compiling and hosting the code and infrastructure yourself. Not often this is feasible.