6 ms·

This is a good instinct. Even if you're using a good E2EE messaging app like Signal, you still trust them not to mitm unless you check the other person's public

This is a good instinct. Even if you're using a good E2EE messaging app like Signal, you still trust them not to mitm unless you check the other person's public key out-of-band. I suspect most people don't do that. Also, there are issues with Telegram's E2EE mode, besides it being disabled by default. More than enough reason not to use it.

bsaul 2y ago
i suspect this particular security hole in the signal protocol is the single reason why whatsapp hasn't been banned yet. They can eavedrop by simply adding a device to a conversation and nobody will notice. Your device will gladly send them decryption keys and provide them with a copy of the message nicely.
- honestjohn 2y ago
  I'm not sure if they can add a participant to an existing conversation, and if they did, your client would at least know. Also don't remember if the client will send message history, but I think Signal doesn't. The simple bad scenario I have in mind is when you're initiating a new chat and the mitm it from the start. Or they could do it halfway through, which would notify you that the other end's key changed, but that message is non-threatening enough and happens enough for random other reasons that most people would probably ignore it.
  - bsaul 2y ago
    not a participant. Whatsapp is multi device ( a single user can have multiple devices, such as a web client, an iphone and a mac app). They can simply register another device as belonging to one of the participant, and everything should be forwarded to them, invisibly.
    - honestjohn 2y ago
      Multi-device mode is new enough that I might be wrong about this, but afaik the web client still needs to get the priv key from your phone, so they can't authorize a new client unilaterally. Or it'd be a really silly hole if they could. Edit: Meant to say, the web client needs to somehow be authorized by the phone, not that it takes the privkey exactly. Probably gets a new key that the phone stores, so the phone is still the "master" device. I wouldn't expect the phone client to happily send the chat history to a new device it didn't authorize locally.
      - deleted 2y ago
        [deleted]
      - bsaul 2y ago
        Maybe the phone transfers a secret to the webclient, and that secret is then used by the other participant to certify it is indeed an "authorized" device, but i was under the impression that you had to rely on the server to correctly give you a list of correct devices for a given participant. i'm happy to know more about that topic if you've got some documentation.
        honestjohn 2y ago
        Someone else here probably knows more than me. I don't want to speculate too much about what it actually does, I just know that the original device takes part in authorizing a new one, so it seems like they can't do it on their own.
        bsaul 2y ago
        i guess it depends if the authorization process reaches the other participants in some way or another ( such as a key derivation mechanism that can be verified by everyone) or if it's just a security feature to strengthen the login process.
        honestjohn 2y ago
        Maybe it's similar to adding a new chat participant, except your client says "btw this is also me." I used that way when designing a toy e2ee app a while back. Or maybe there is a central repo of each user's per-device pub keys, and your client signs its updates to it using the original pub key so it's tamper-evident. Maybe there's some key derivation mechanism so the new pubkey is self-evidently owned by the first one, never heard of one though.
- honestjohn 2y ago
  Separate from our other convo, I just found this spicy note in Telegram's manual: "Multi-device End-to-end encrypted chats are a mess[...] Most of our competitors (notably, Whatsapp and iMessage) solve these problems in ways that make their end-to-end encryption useless (this is a big topic, so requires a separate manual)." And links to a TODO page. Can't just say that and leave us hanging! https://tsf.telegram.org/manuals/e2ee-simple https://tsf.telegram.org/manuals/e2ee-simple My own distrust for Telegram aside, I like how these pages seem to be written by an engineer and not a PR person.
novakboskov 2y ago
Well, if you're communicating with someone on Signal and they indeed receive your messages, you're safe to assume they are the public key holder. The critical part is the secret key management. In other words, are they _the only_ ones who hold the secret key?
- honestjohn 2y ago
  No, your client asks Signal's server for the other end's public key. There's fundamentally no way for Signal's server to prove to your client that the pubkey you're encrypting for is indeed the one owned by the phone number you keyed in.
  - hughesjj 2y ago
    It offers a fingerprint you're supposed to validate over sneakernet but people are lazy
    - rvnx 2y ago
      and Google Play offers the possibility to distribute an update only to specific e-mail addresses, so if there is a need to compromise users with a malicious update that shows another fingerprint it's really doable (or just copy the messages, like Skype was doing with TOM-Skype).
  - stavros 2y ago
    To clarify, there's no way for any software to do that. You need to somehow validate the keys' ownership out of band.
- PeterisP 2y ago
  No, that someone would also be able to indeed receive your messages if there is an attacker in the middle who gave you his public key and is then forwarding the message using a channel established with the true recipient's public key. Message secrecy does rely on being able to authenticate the recipient's public key.

bsaul 2y ago

i suspect this particular security hole in the signal protocol is the single reason why whatsapp hasn't been banned yet. They can eavedrop by simply adding a device to a conversation and nobody will notice. Your device will gladly send them decryption keys and provide them with a copy of the message nicely.

honestjohn 2y ago
I'm not sure if they can add a participant to an existing conversation, and if they did, your client would at least know. Also don't remember if the client will send message history, but I think Signal doesn't. The simple bad scenario I have in mind is when you're initiating a new chat and the mitm it from the start. Or they could do it halfway through, which would notify you that the other end's key changed, but that message is non-threatening enough and happens enough for random other reasons that most people would probably ignore it.
- bsaul 2y ago
  not a participant. Whatsapp is multi device ( a single user can have multiple devices, such as a web client, an iphone and a mac app). They can simply register another device as belonging to one of the participant, and everything should be forwarded to them, invisibly.
  - honestjohn 2y ago
    Multi-device mode is new enough that I might be wrong about this, but afaik the web client still needs to get the priv key from your phone, so they can't authorize a new client unilaterally. Or it'd be a really silly hole if they could. Edit: Meant to say, the web client needs to somehow be authorized by the phone, not that it takes the privkey exactly. Probably gets a new key that the phone stores, so the phone is still the "master" device. I wouldn't expect the phone client to happily send the chat history to a new device it didn't authorize locally.
    - deleted 2y ago
      [deleted]
    - bsaul 2y ago
      Maybe the phone transfers a secret to the webclient, and that secret is then used by the other participant to certify it is indeed an "authorized" device, but i was under the impression that you had to rely on the server to correctly give you a list of correct devices for a given participant. i'm happy to know more about that topic if you've got some documentation.
      - honestjohn 2y ago
        Someone else here probably knows more than me. I don't want to speculate too much about what it actually does, I just know that the original device takes part in authorizing a new one, so it seems like they can't do it on their own.
        bsaul 2y ago
        i guess it depends if the authorization process reaches the other participants in some way or another ( such as a key derivation mechanism that can be verified by everyone) or if it's just a security feature to strengthen the login process.
        honestjohn 2y ago
        Maybe it's similar to adding a new chat participant, except your client says "btw this is also me." I used that way when designing a toy e2ee app a while back. Or maybe there is a central repo of each user's per-device pub keys, and your client signs its updates to it using the original pub key so it's tamper-evident. Maybe there's some key derivation mechanism so the new pubkey is self-evidently owned by the first one, never heard of one though.
honestjohn 2y ago
Separate from our other convo, I just found this spicy note in Telegram's manual: "Multi-device End-to-end encrypted chats are a mess[...] Most of our competitors (notably, Whatsapp and iMessage) solve these problems in ways that make their end-to-end encryption useless (this is a big topic, so requires a separate manual)." And links to a TODO page. Can't just say that and leave us hanging! https://tsf.telegram.org/manuals/e2ee-simple https://tsf.telegram.org/manuals/e2ee-simple My own distrust for Telegram aside, I like how these pages seem to be written by an engineer and not a PR person.

novakboskov 2y ago

Well, if you're communicating with someone on Signal and they indeed receive your messages, you're safe to assume they are the public key holder. The critical part is the secret key management. In other words, are they _the only_ ones who hold the secret key?

honestjohn 2y ago
No, your client asks Signal's server for the other end's public key. There's fundamentally no way for Signal's server to prove to your client that the pubkey you're encrypting for is indeed the one owned by the phone number you keyed in.
- hughesjj 2y ago
  It offers a fingerprint you're supposed to validate over sneakernet but people are lazy
  - rvnx 2y ago
    and Google Play offers the possibility to distribute an update only to specific e-mail addresses, so if there is a need to compromise users with a malicious update that shows another fingerprint it's really doable (or just copy the messages, like Skype was doing with TOM-Skype).
- stavros 2y ago
  To clarify, there's no way for any software to do that. You need to somehow validate the keys' ownership out of band.
PeterisP 2y ago
No, that someone would also be able to indeed receive your messages if there is an attacker in the middle who gave you his public key and is then forwarding the message using a channel established with the true recipient's public key. Message secrecy does rely on being able to authenticate the recipient's public key.