[jandrewrogers]

> "Messages on WhatsApp are end-to-end encrypted by default, meaning only the recipients and not even WhatsApp can see them."

The handling and metadata around encrypted messages is nearly as exploitable as the actual message contents. End-to-end encryption is necessary but not sufficient. The infrastructure has to be designed to minimize risk of other forms of exploitive analysis as well but in the case of WhatsApp that is essentially their business model.

[dijit]

If the network controls the endpoints; then E2EE is meaningless.

[benced]

What implementation of end to end encryption doesn't involve this?

[dijit]

OTR, for IRC/XMPP, PGP for Email and Olm/Megolm provided by Element for Matrix operators.

Essentially the software creating the keys is not controlled by the same entity controlling the transmission method.

In email/matrix you have an additional protection in that you can host your own server; the best protection is the one you never have the possibility of traffic being diverted, and even if it was it would be encrypted so that the server doesn’t leak anyway, security is like an onion after all.

[jeroenhd]

If you think WhatsApp leaves a lot of metadata on the table for analysis, try doing a Matrix chat. You get a plaintext view of which device used which key to send which message ID to which room/person. If the message is a reply, you get the message ID your new message is a reply to in plaintext as well.

Without even looking at things like HTTP headers, this is what the metadata an E2EE-encrypted message (with verified+cross-signed keys) looks like, with specific identifiers censored just in case:

    {
      "type": "m.room.encrypted",
      "sender": "@.......:jeroenhd.nl",
      "content": {
        "algorithm": "m.megolm.v1.aes-sha2",
        "ciphertext": "AwgAEqAC/..........",
        "device_id": "EDNM......",
        "sender_key": "+rKR.......",
        "session_id": "H3Oyob........",
        "m.relates_to": {
          "m.in_reply_to": {
            "event_id": "$5qFg........"
          }
        }
      },
      "origin_server_ts": 17507.......,
      "unsigned": {
        "membership": "join",
        "age": 127,
        "transaction_id": "m17507........."
      },
      "event_id": "$_KBk.......",
      "room_id": "!.........:jeroenhd.nl"
    }

Unlike on platforms like Whatsapp, these message envelopes are available to anyone with access to either a session token or the user's password. The E2EE keys require a bit of extra verification, but you don't need those to build a pretty solid who-talks-to-who-when network even in encrypted chatrooms.

I understand why they implemented some of the metadata this way, but the encryption-stapled-to-unencrypted-messaging approach just leaves a lot to be desired. Signal, on the other hand, leaks pretty much nothing.

[eitland]

Irony over irony I think you can include Telegram here:

- yes not end-to-end encrypted by default

- but I haven't seen any complaints about their end-to-end encryption, except that it isn't enabled by default

- and unlike WhatsApp they publish reproducible builds so we can know the endpoints do what the source code says