7 ms·

It wouldn't surprise me as recently the app tried to get me to trust an untrusted cert.

• freedomben 6y ago
  yikes, if they ended up murdering Keybase and still ship crap, I will never forgive them.
  • sfuller808 6y ago
    whats the post-keybase landscape?
• 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."
    • 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.