6 ms·

I wonder if they'll make it unverifiable (like Keybase[1]), opportunistic (like WhatsApp[2]), requiring confirmation in every call so nobody practically uses it

I wonder if they'll make it unverifiable (like Keybase[1]), opportunistic (like WhatsApp[2]), requiring confirmation in every call so nobody practically uses it (like Telegram[3]), hide the key verification screen so 0.001% practically does it (like Signal[4]), uses long-lived keys that can decrypt all historical traffic (like PGP), have encrypted mode be some second-rate mode that removes most of the features you need (like Telegram's encrypted chats; I see that the announcement already mentions some unavailable features when you turn on encryption), or if they'll have a novel trick to break the encryption at will. At a minimum, I expect it'll be an obfuscated binary with auto-updates and no published independent code reviews. Let's hope Microsoft surprises us all! (as I see most of the comments being skeptical) [1] Try to verify which encryption keys your mobile keybase chat client is using or if the server injected its own keys. Bonus points if you spot the "this chat is end-to-end encrypted" banner while you're doing this. Details: https://security.stackexchange.com/questions/222055/how-can-i-verify-keybases-end-to-end-encryption-between-me-and-a-friend https://security.stackexchange.com/questions/222055/how-can-... [2] You have to go into settings to enable even just seeing key changes, let alone that the client stops you from sending messages when a previously verified key changes. [3] Telegram calls have encryption, but every time you have to verify the emojis again and again instead of it just storing the other party's key. [4] Threema shows the verification status for every chat. My mother in law, from her own volition, wanted to verify keys with me. She later tried Signal to compare, since she needs to use something encrypted for her work (medical data), but didn't get that she had to verify keys on Signal, too. I find that even techies often don't know where to find that in Signal, or even realize that it's required for the security claims to apply.

Spooky23 5y ago
I doubt it, that’s not the kind of feature that Teams customers want. Most businesses have a need for discovery and audit, and Teams is a phone application with lawful interception needs, so you’re always going to have an interception capability. End of the day, it’s a way to sell the full Microsoft stack… the only way to have an E2E encrypted meeting is to not allow dial-in, which is a way to encourage adoption of Teams as a unified communication solution. (Which is the strategy Zoom is attempting as well)
- smolder 5y ago
  Lawful interception is a joke. Dragnet spying is what passive encryption breaking enables, and it's what the authorities are always after, not targeted surveillence for a specific purpose. If there were any respect for the fourth amendment by LEO and the government at large, I might sympathize a bit more with lawful interception schemes. Meanwhile, in reality, I look forward to the need to have every person location-tracked even without a cell phone. I'll cynically bet its part of "the discussion" by the time I'm retirement age. Being untracked just presents too many dangers!
weird-eye-issue 5y ago
Can you elaborate on Signal? Isn't it E2E by default?
- jMyles 5y ago
  It is indeed. The pattern that OP apparently doesn't like is that the cryptographic material needed to actually verify the other party is somewhat buried, and as a result surely few people do this. As critiques of signal go, it is perhaps not entirely unfounded, but I'm not sure it'd be my first - or even second - qualm.
  - lucgommans 5y ago
    This is indeed what I meant. Of course it's encrypted by default, but unless you verify the keys, you're trusting the server to be honest which is not the point of end-to-end encryption. Because you can verify keys, the chance of them getting caught inserting interception keys is pretty decent (if a small % of users does the verification), so they're quite likely to remain honest and anyone who might hack a Signal server would also think twice where the gain is worth triggering this indicator of compromise.
    - tialaramex 5y ago
      You are trusting the server to be honest, but maybe not when you think. In Signal's design, participants have a long term identity key, and the thing you're verifying is essentially just the combination of your long term identity key with the other party's long term identity key, but deterministically ordered so that you both see the exact same value. They call this the "Safety Number". So e.g. maybe your identity can be summarised as A4 and Jim's identity is C6, Signal will show you the value A4C6 as the "Safety Number" for Jim, while Jim also sees A4C6 as the "Safety Number" for lucgommans. This value is calculated by your client (and Jim's client). The server could present you a new long term identity key for Jim (because Jim's phone dropped dead and he bought a new one, or because the Secret Police want to intercept messages for Jim) but this triggers your client to warn you that the Safety Number changed and you need to decide if this is still Jim. The Safety Number isn't calculated for each messages, or call, or whatever, because it's made from these long term keys. The Signal UI reflects the reality that the only way to be sure Jim is seeing the same Safety Number as you is to physically meet up and compare. I think it has pretty nice affordance for that scenario, you can scan a QR code from another Signal user to verify them. It's tempting to think, but I could just read my Safety Number out, on this call, and then we verify that way. Signal won't prevent you from attempting this, but it actually isn't necessarily safe, so it also doesn't encourage that. Can a Nation State adversary fake up the "verification" step in a voice call? Maybe. Would you notice if they tried? Maybe. Best to sidestep the maybes entirely and if your threat model requires it just actually perform Verification of the Safety Number in person.
golergka 5y ago
> [3] Telegram calls have encryption, but every time you have to verify the emojis again and again instead of it just storing the other party's key. I was under impression that this feature was a "gamification" of encryption for completely non-technical people who otherwise wouldn't even think about it, to be honest.
upofadown 5y ago
>...uses long-lived keys that can decrypt all historical traffic (like PGP)... It is pretty clear from what the article describes that they are not doing some sort of static encryption thing like PGP. They are providing a system that is completely under the control of a central authority. Static encryption would normally give control to the end users at the cost having the users responsible for their own key information. They are not going for any sort of user empowerment here.
- lucgommans 5y ago
  > They are providing a system that is completely under the control of a central authority. That could be the dictionary definition of the opposite of end-to-end encryption. Since the claim is that it will be e2ee, I'd assume they at least make an attempt to meet the definition and subvert it in some other way.
  - hulitu 5y ago
    It the classical definition of end to end encription: you encrypt it and use _our_ channel to send the keys to the recipient of the message. We promise ( rotfl) that we won't look.
naikrovek 5y ago
why can't it be like (or actually be) TLS? that seems easy to implement in a tool based on Electron.
- kwindla 5y ago
  WebRTC media transports use DTLS-SRTP, which is (loosely) the UDP/RTP version of TLS. In a peer-to-peer WebRTC session, running on -- say -- a non-hacked version of Chrome, you can be pretty confident that you already have good end-to-end encryption. The problem is that Teams calls are generally routed through media servers (they are not peer-to-peer sessions). So the encryption is from each client to/from the media server, not "end-to-end." In a Teams call running on -- say -- a non-hacked version of Chrome, you can be pretty confident you have good on-the-wire encryption. But Microsoft can decrypt your media streams as they pass through the Teams media servers. The media server has several reasons it (probably) needs to decrypt the SRTP streams. First, the WebRTC standard, today, does not specify any mechanism for "end-to-end" encryption of media passing through a media server. The WebRTC specification mandates support for DTLS-SRTP, which has very nice "zero trust" properties. Certificate fingerprints are exchanged out-of-band (via the application-level signaling channel) but the actual encryption keys are generated in-band (via the WebRTC media channels) and never exposed. But, with this approach, it's not possible to share keys between multiple participants, which means it's not possible to route an encrypted media stream to multiple receiving clients. There was a debate during the WebRTC standards process about whether to also support SDES, in which keys are exchanged via the signaling channel. Because you have to trust the signaling channel, and it's trivial to log keys, SDES has obvious attack surfaces that DTLS-SRTP doesn't. SDES support was dropped from the draft standard. Most WebRTC implementations only implement DTLS-SRTP. Second, the media server needs some codec-level information that is part of the encrypted SRTP stream in order to route and manage the video. This is solvable with RTP header extensions that pull all the data needed by the media server out of the encrypted RTP payload and into the unencrypted RTP header. But each codec needs its own header extension, which needs to be standardized and supported by WebRTC implementations and media servers. Third, some things you probably want the media server to do at least some of the time require decrypting the media streams (keyframe regeneration, recording, transcription, bridging to telephone dial-in). All of which suggests that what it really means to promise "end-to-end" encryption is ... at least a little bit up for debate. If you trust your signaling channel but not your media server, and both are provided by the same application or service, is that end-to-end encryption? If you trust your media server some of the time (when you want to record a session, for example) but not all the time, how do you verify that the appropriate key exchange mechanism is being used at the appropriate times? There is an experimental API (WebRTC Insertable Streams), and an IETF Draft (Secure Frames), that together may allow true end-to-end encryption in the near future in a standards-compliant fashion. Note, however, that this still leaves key generation and exchange up to the application. Nice overview of WebRTC Insertable Streams and Secure Frames: https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ https://webrtcbydralex.com/index.php/2020/03/30/secure-frame...

Spooky23 5y ago

I doubt it, that’s not the kind of feature that Teams customers want. Most businesses have a need for discovery and audit, and Teams is a phone application with lawful interception needs, so you’re always going to have an interception capability. End of the day, it’s a way to sell the full Microsoft stack… the only way to have an E2E encrypted meeting is to not allow dial-in, which is a way to encourage adoption of Teams as a unified communication solution. (Which is the strategy Zoom is attempting as well)

smolder 5y ago
Lawful interception is a joke. Dragnet spying is what passive encryption breaking enables, and it's what the authorities are always after, not targeted surveillence for a specific purpose. If there were any respect for the fourth amendment by LEO and the government at large, I might sympathize a bit more with lawful interception schemes. Meanwhile, in reality, I look forward to the need to have every person location-tracked even without a cell phone. I'll cynically bet its part of "the discussion" by the time I'm retirement age. Being untracked just presents too many dangers!

weird-eye-issue 5y ago

Can you elaborate on Signal? Isn't it E2E by default?

jMyles 5y ago
It is indeed. The pattern that OP apparently doesn't like is that the cryptographic material needed to actually verify the other party is somewhat buried, and as a result surely few people do this. As critiques of signal go, it is perhaps not entirely unfounded, but I'm not sure it'd be my first - or even second - qualm.
- lucgommans 5y ago
  This is indeed what I meant. Of course it's encrypted by default, but unless you verify the keys, you're trusting the server to be honest which is not the point of end-to-end encryption. Because you can verify keys, the chance of them getting caught inserting interception keys is pretty decent (if a small % of users does the verification), so they're quite likely to remain honest and anyone who might hack a Signal server would also think twice where the gain is worth triggering this indicator of compromise.
  - tialaramex 5y ago
    You are trusting the server to be honest, but maybe not when you think. In Signal's design, participants have a long term identity key, and the thing you're verifying is essentially just the combination of your long term identity key with the other party's long term identity key, but deterministically ordered so that you both see the exact same value. They call this the "Safety Number". So e.g. maybe your identity can be summarised as A4 and Jim's identity is C6, Signal will show you the value A4C6 as the "Safety Number" for Jim, while Jim also sees A4C6 as the "Safety Number" for lucgommans. This value is calculated by your client (and Jim's client). The server could present you a new long term identity key for Jim (because Jim's phone dropped dead and he bought a new one, or because the Secret Police want to intercept messages for Jim) but this triggers your client to warn you that the Safety Number changed and you need to decide if this is still Jim. The Safety Number isn't calculated for each messages, or call, or whatever, because it's made from these long term keys. The Signal UI reflects the reality that the only way to be sure Jim is seeing the same Safety Number as you is to physically meet up and compare. I think it has pretty nice affordance for that scenario, you can scan a QR code from another Signal user to verify them. It's tempting to think, but I could just read my Safety Number out, on this call, and then we verify that way. Signal won't prevent you from attempting this, but it actually isn't necessarily safe, so it also doesn't encourage that. Can a Nation State adversary fake up the "verification" step in a voice call? Maybe. Would you notice if they tried? Maybe. Best to sidestep the maybes entirely and if your threat model requires it just actually perform Verification of the Safety Number in person.

golergka 5y ago

> [3] Telegram calls have encryption, but every time you have to verify the emojis again and again instead of it just storing the other party's key. I was under impression that this feature was a "gamification" of encryption for completely non-technical people who otherwise wouldn't even think about it, to be honest.

upofadown 5y ago

>...uses long-lived keys that can decrypt all historical traffic (like PGP)... It is pretty clear from what the article describes that they are not doing some sort of static encryption thing like PGP. They are providing a system that is completely under the control of a central authority. Static encryption would normally give control to the end users at the cost having the users responsible for their own key information. They are not going for any sort of user empowerment here.

lucgommans 5y ago
> They are providing a system that is completely under the control of a central authority. That could be the dictionary definition of the opposite of end-to-end encryption. Since the claim is that it will be e2ee, I'd assume they at least make an attempt to meet the definition and subvert it in some other way.
- hulitu 5y ago
  It the classical definition of end to end encription: you encrypt it and use _our_ channel to send the keys to the recipient of the message. We promise ( rotfl) that we won't look.

naikrovek 5y ago

why can't it be like (or actually be) TLS? that seems easy to implement in a tool based on Electron.

kwindla 5y ago
WebRTC media transports use DTLS-SRTP, which is (loosely) the UDP/RTP version of TLS. In a peer-to-peer WebRTC session, running on -- say -- a non-hacked version of Chrome, you can be pretty confident that you already have good end-to-end encryption. The problem is that Teams calls are generally routed through media servers (they are not peer-to-peer sessions). So the encryption is from each client to/from the media server, not "end-to-end." In a Teams call running on -- say -- a non-hacked version of Chrome, you can be pretty confident you have good on-the-wire encryption. But Microsoft can decrypt your media streams as they pass through the Teams media servers. The media server has several reasons it (probably) needs to decrypt the SRTP streams. First, the WebRTC standard, today, does not specify any mechanism for "end-to-end" encryption of media passing through a media server. The WebRTC specification mandates support for DTLS-SRTP, which has very nice "zero trust" properties. Certificate fingerprints are exchanged out-of-band (via the application-level signaling channel) but the actual encryption keys are generated in-band (via the WebRTC media channels) and never exposed. But, with this approach, it's not possible to share keys between multiple participants, which means it's not possible to route an encrypted media stream to multiple receiving clients. There was a debate during the WebRTC standards process about whether to also support SDES, in which keys are exchanged via the signaling channel. Because you have to trust the signaling channel, and it's trivial to log keys, SDES has obvious attack surfaces that DTLS-SRTP doesn't. SDES support was dropped from the draft standard. Most WebRTC implementations only implement DTLS-SRTP. Second, the media server needs some codec-level information that is part of the encrypted SRTP stream in order to route and manage the video. This is solvable with RTP header extensions that pull all the data needed by the media server out of the encrypted RTP payload and into the unencrypted RTP header. But each codec needs its own header extension, which needs to be standardized and supported by WebRTC implementations and media servers. Third, some things you probably want the media server to do at least some of the time require decrypting the media streams (keyframe regeneration, recording, transcription, bridging to telephone dial-in). All of which suggests that what it really means to promise "end-to-end" encryption is ... at least a little bit up for debate. If you trust your signaling channel but not your media server, and both are provided by the same application or service, is that end-to-end encryption? If you trust your media server some of the time (when you want to record a session, for example) but not all the time, how do you verify that the appropriate key exchange mechanism is being used at the appropriate times? There is an experimental API (WebRTC Insertable Streams), and an IETF Draft (Secure Frames), that together may allow true end-to-end encryption in the near future in a standards-compliant fashion. Note, however, that this still leaves key generation and exchange up to the application. Nice overview of WebRTC Insertable Streams and Secure Frames: https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/ https://webrtcbydralex.com/index.php/2020/03/30/secure-frame...