Comment on An analysis of X(Twitter)'s new XChat features shows that X can probably decrypt users' messages, as it holds users' private keys on its servers

• EncryptKeeper@lemmy.world ⁨1⁩ ⁨day⁩ ago

  No it doesn’t, and I defined E2EE exactly one way.

  It doesn’t matter if they store a copy of your message on an intermediary server, the keyword there is intermediary. They are not the recipient, so they should not have the ability to decrypt the content of the message, only the recipient should. If they are able to decrypt your message, it’s not E2EE.

  A cloud drive is an entirely different case because the cloud drive is not an intermediary. They are the second E in E2EE. A cloud drive can have the ability to decrypt your data and still be E2EE because they are the recipient.

  source

  • Lifter@discuss.tchncs.de ⁨18⁩ ⁨hours⁩ ago

    You probably didn’t understand me. I’m saying that a company can just arbitrarily decide (like you did) that the server is the “end” recipient (which I disagree with). That can be done for chat messages too.

    You send the message “E2EE” to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.

    By changing the recipient “end”, we can arbitrarily decode the message then.

    I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.

    source

    • EncryptKeeper@lemmy.world ⁨5⁩ ⁨hours⁩ ago

      I’m saying that a company can just arbitrarily decide (like you did) that the server is the “end” recipient (which I disagree with).

      They cannot. Thats not how E2EE works. If they can arbitrarily decide that, then it isn’t E2EE.

      That can be done for chat messages too.

      It cannot, if you’re using E2EE.

      You send the message “E2EE” to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport.

      That’s not how E2EE works. What you are describing is encryption that is not end-to-end. E2EE was designed the solve the issue you’re describing.

      This fully fits your definition for the cloud storage example.

      It does not. Cloud storage is a product you’d use to store your data for your own use at your own discretion.

      I would argue that the cloud provider is not the recipient of files uploaded there

      It is if you uploaded files to it, like on purpose.

      You’re confusing E2EE and non E2EE encryption.

      source
    • Lifter@discuss.tchncs.de ⁨18⁩ ⁨hours⁩ ago

      Alternatively, we need to stop saying E2EE is safe at all, for any type of data, because or the arbitrary usage.

      source

      • EncryptKeeper@lemmy.world ⁨4⁩ ⁨hours⁩ ago

        We don’t need to stop saying E2EE is safe, because it is. There is no arbitrary usage. Either it’s E2EE. If a company lies to you and tells you it’s E2EE and it’s not E2EE that’s not arbitrary usage, it’s just a lie.

        source