9 ms·

> Mr. Zuckerberg has also ordered all of the apps to incorporate end-to-end encryption, the people said, a significant step that protects messages from being vi

> Mr. Zuckerberg has also ordered all of the apps to incorporate end-to-end encryption, the people said, a significant step that protects messages from being viewed by anyone except the participants in the conversation. I don't blame NYT for getting this wrong wrt WhatsApp but it bears repeating: if you let someone else broker the key exchange, you trust them implicitly. That is to say that IMO this is not truly trustworthy "end to end encryption". To add insult to injury, WhatsApp permits rekeying to take place without any indication to the conversation's participants [in the default settings].

yholio 8y ago
This is fundamental. If Facebook messages are still to work as before, with a web interface, an archive etc. then you need to supply Facebook servers with a decryption key. You no longer have end to end encryption. And I don't really see how they could get rid of the web features, it represents a massive number of FB Messenger users. This ties nicely with the older pressures from Zuckerberg to monetize WhatsApp and the resistance of the founders for security reasons, this most likely means access to the conversation plaintext.
- untog 8y ago
  WhatsApp Web already provides this, by connecting to the phone and proxying messages through it. Of course, that also requires implicit trust in WhatsApp Web, but it is possible. And using WhatsApp requires implicit trust in Facebook anyway, so...
  - est31 8y ago
    It still requires you to run the WhatsApp phone app though. I doubt that facebook wants to require all of their users to have phones. You can reimplement WhatsApp's functionality in client side JS but then you get into deep technical problems rooted from the fact that js is, in general, ephemeral and not something permanent compared to an ios/android app. E.g. when someone logs onto facebook on a their friend's computer to check their messages you want everything to be smooth including message search but in order to provide message search, either the server needs access to the plaintext or the client needs to download the entire message history... If there's an app the client already has the entire history so that's no problem, but it is a problem with ephemeral Javascript. Another problem you run into is that Facebook can serve specifically manipulated Javascript just for you ^ TM because you are an interesting target or something. For Android/iOS this would require an app update and need to go through a third party and I haven't heard that google or apple give you the option to push a specific app to a specific device.
- basch 8y ago
  you could type the key into each client each time, no? isnt that how things like dashlane work? it sends the encrypted historical blob to your device, your device decodes it.
  - throwawaylolx 8y ago
    I don't think such unfriendly UX would ever be considered in such a mainstream service
    - basch 8y ago
      the OPTION to start an encrypted chat, with a chat specific password?
      - instakill 8y ago
        Or storing the key in localstorage?
        basch 8y ago
        i guess by "each time" i was being somewhat ambiguous. it could mean each login, or each install, or each time the session clears.
        yholio 8y ago
        To enable end-to-end encryption, you need more than local storage, you need local computation using local execution of signed and reproducible code. Javascript in browsers is fundamentally not such a platform, mobile applications are - to the degree you trust Google, Apple etc.
    - shawnz 8y ago
      You already have to login with a username and password to access Facebook, unlike whatsapp where your phone is the sole key. Facebook could just construct the key at logon time based on the user's password.
- NolF 8y ago
  Couldn't the messages be encrypted using the user password?
yots 8y ago
Also, last time I checked Facebook still sees all the links you exchange in the conversation.
bouncing 8y ago
> if you let someone else broker the key exchange, you trust them implicitly. Sort of. Yes, they could serve you a MITM key, but it would be easily discoverable when you compare security codes in the client. And since the client is widely distributed on major app stores, it would be very risky to ship a compromised client. Ultimately key exchange is a hard problem to solve. Notice that Signal doesn't do anything that much different; Signal does the key exchange and unless you verify each user's key offline, you have to trust it. Both WhatsApp and Signal have an option to display a notice when keys change, but Signal's is on by default. Overall it's still pretty damn good. WhatsApp is perhaps the only major form of consumer communication where, by default and with no opt-out, every single chat really is fully encrypted using a widely respected protocol (libsignal). That's not nothing.
- madeofpalk 8y ago
  iMessage, though operating at a smaller scale than WhatsApp
  - bouncing 8y ago
    Indeed! iMessage should get an honorable mention. Having lived outside of the US for a few years, sometimes I forget it exists, because here even people who both have iPhones use WhatsApp. iMessage deserves an honorable mention, but with some caveats. As I recall and quickly Googled: There have been some concerns with their security: https://www.schneier.com/blog/archives/2016/03/imessage_encryp.html https://www.schneier.com/blog/archives/2016/03/imessage_encr... https://www.pandasecurity.com/mediacenter/technology/need-know-imessage-security-flaw/ https://www.pandasecurity.com/mediacenter/technology/need-kn... https://www.tomshardware.com/news/imessage-weak-encryption-matthew-green,32466.html https://www.tomshardware.com/news/imessage-weak-encryption-m... Additionally, iMessage doesn't have any means of out-of-band key verification, so you actually have to trust Apple to faithfully exchange keys and there's no way to verify that it's done so. iMessage also tells you after a message is sent (via the color of a bubble) whether the recipient received it using iMessage. That's not very good assurance if, say, you're messaging a journalist in an authoritarian country. Will it go out over SMS or iMessage? You can find out, but even a little bit of doubt about that can have significant consequences. I'm glad iMessage does do encryption like it does, but it's no replacement for Signal and WhatsApp uses libsignal for its encryption.
crystaln 8y ago
For sure if you are using any app or OS over which you don't have complete knowledge and control, and which isn't entirely unhackable, you are trusting someone somewhere. Application companies will always be able to backdoor their apps. What e2e encryption does do is make messages nearly impossible to be intercepted in transit or on a massive scale by anyone without the cooperation of the company.
- wyldfire 8y ago
  > What e2e encryption does do is make messages nearly impossible to be intercepted in transit or on a massive scale by anyone without the cooperation of the company. I don't understand why you and others in this thread describe it this way. "end to end" in this description sounds a lot like "transport security" -- like what you get from TLS (https, e.g.). How is this version of "end to end" (where are the ends?) any better than TLS?
  - lmm 8y ago
    > I don't understand why you and others in this thread describe it this way. "end to end" in this description sounds a lot like "transport security" -- like what you get from TLS (https, e.g.). How is this version of "end to end" (where are the ends?) any better than TLS? TLS is client-server oriented. When a messaging system uses "transport security", like Facebook Messenger, that normally means that your client's connection to Facebook's server is encrypted, but Facebook's server still has access to your message plaintext. Whereas an "end to end" encrypted system would encrypt messages on your client that are only encrypted by the person you're talking to's client. (I'm similarly skeptical about how much difference this makes in practice - I don't know what the threat model is where you trust a closed-source app and closed source google play services but don't trust the same company's servers. But it is a real distinction in behaviour)
    - wyldfire 8y ago
      You may have misunderstood my reply to mean that I don't understand what's different between TLS and end to end encryption. In fact I don't understand the difference between TLS and -- let's call it E2E' (that which might be "end to end encryption"). If E2E' permits the message broker to intercept messages, does it satisfy the conventional definition of "end to end encryption"? No, certainly not. Is it any better than TLS? No, not in my opinion. Here's what I quoted, which I believe to be E2E': > What e2e encryption does do is make messages nearly impossible to be intercepted in transit or on a massive scale by anyone without the cooperation of the company.
rafiki6 8y ago
I guess it's fair to assume that when we say "the conversation's participants" we explicitly mean everyone except the broker. I think it's important in this day and age to accept that the broker is now a conversation participant as well. Maybe we should look more into P2P messaging software.
- wyldfire 8y ago
  > the broker is now a conversation participant as well. I don't agree. This is the antithesis of the intent of the term "end to end encryption." Otherwise you could just use TLS to secure each of the {client->broker} connections and then you could call it "end to end".
- rafiki6 8y ago
  I don't see why my comment was down voted. I made a valid argument that the expectation of the broker not being privy to the conversation is a bit unreasonable and we should further explore P2P.
throwawaymath 8y ago
I think end-to-end encryption is currently undergoing a crisis of definition. Within the security and cryptography communities, implementations of secure messaging like Whatsapp and iMessage are considered to be end-to-end encrypted communications. The philosophical intention of end-to-end encryption is to enable communication through infrastructure which you do not trust. Beyond the technical considerations, different demographics have various expectations about what end-to-end encryption means. Sometimes their position is that end-to-end encryption does not exist without decentralization. Some want to have a fully federated protocol. Others believe that allowing an intermediary to broker key exchange invalidates the end-to-end confidentiality and authenticity assurances. This often leads to nitpicking about what defines end-to-end encryption which, while a useful exercise in its own right, doesn't capture the heart of the grievances at play. In many cases it would be more productive to talk more directly about expectations regarding the security and privacy of a service or protocol rather than whether or not it fulfills an underspecified set of criteria. This is to say that you can make a compelling argument that allowing a third party to broker your key exchange is insufficiently secure for you. But if you anchor that critique to whether or not the protocol satisfies end-to-end encryption, you're inviting rebuttals that don't substantially respond to what your critique is. Whether or not something satisfies end-to-end encryption is somewhat less important than whether or not you think it holistically satisfies what you consider to be strong confidentiality and authenticity assurances. If your problem is that you don't want a company like Facebook bootstrapping the key exchange for you, then you should defend that (valid) opinion by choosing a different set of criteria to work with.
- feanaro 8y ago
  Decentralization/federation and the existence of third-party brokers don't really come into play here. What is required is a. a cryptographically secure protocol b. an UI that is strict about checking that the keys and signatures match and is loud about notifying the user when they don't c. an open source client
  - throwawaymath 8y ago
    An open source client is not required for end-to-end encryption. Do you see what I'm getting at? We're quibbling about a technically precise definition instead of what you'd like to see in a secure messaging application.
FrankDixon 8y ago
to me all this end-to-end business sounds too much like marketing. As long as you have to use the clients provided by facebook, it doesn't matter that the chats are end-to-end encrypted. Facebook controls the clients and as such can do whatever it likes with your chats (or whatever you agreed to)
- throwawaymath 8y ago
  End-to-end encryption is about decomposing trusted parties and compartmentalizing untrusted infrastructure. There are meaningful differences between end-to-end encryption and server-side encryption. These differences are entirely orthogonal to the question of whether or not you can verify the client or the server. This is what I was getting at in my other comment. If you’re going to reject end-to-end encryption because you can’t verify the client, you’re looking at a very different set of criteria to establish the confidentiality and authenticity assurances you want. In particular, you are at a point where it’s difficult to establish a secure channel unless you’re using a fully decentralized, federated protocol with a server you stood up yourself.
  - megous 8y ago
    Yes, that's why you need independently developed and independently distributed client software. Otherwise there's no meaningful compartmentalization. The parent poster is not rejecting end-to-end crypto itself, but how it's typically done. (on a locked phone you don't really control in an autoupdating app you don't control at all) Web based end to end encryption is even more ridiculous (say mega.nz for example), because then it's even more trivial to distribute different code to differnet users.
    - throwawaymath 8y ago
      There is meaningful compartmentalization without independent distribution and development. That point was the entire basis of my comment.
vorticalbox 8y ago
You can enable a notification in the settings when a person keys changes.
fortenforge 8y ago
What application would you say has "real" e2e encryption? Signal and all the other apps have exactly the same problem right? If you don't compare your keys offline, you're always at risk for this attack. You can't build cryptography out of sand.
- rhizome 8y ago
  At the very least, Signal notifies on rekeying and in both the desktop and Android versions it doesn't appear to be changeable.
  - indigo945 8y ago
    WhatsApp also notifies on rekeying. A yellow message is shown warning that "your conversation partner's security codes have changed" or something of the sort.
    - kikoreis 8y ago
      It's an option. And it's disabled by default.
- mach5 8y ago
  keybase does! https://keybase.io/ https://keybase.io/
  - indigo945 8y ago
    How does keybase do key exchanges?
  - lucb1e 8y ago
    You're saying at Keybase you don't have to compare your fingerprints out of band?
    - 0xb100db1ade 8y ago
      Correct. Key verification is done by looking at signatures on a given user's linked social networks / websites etc
DonbunEf7 8y ago
I have a hard time believing Zuckerberg would purposely exclude himself from the conversation. You know what's bizarre to me? Most US states are either one party consent or 2 party consent states. Meaning to record a conversation, at least one party must consent to the conversation being recorded. So how does this not apply at all to private conversations online?

yholio 8y ago

This is fundamental. If Facebook messages are still to work as before, with a web interface, an archive etc. then you need to supply Facebook servers with a decryption key. You no longer have end to end encryption. And I don't really see how they could get rid of the web features, it represents a massive number of FB Messenger users. This ties nicely with the older pressures from Zuckerberg to monetize WhatsApp and the resistance of the founders for security reasons, this most likely means access to the conversation plaintext.

untog 8y ago
WhatsApp Web already provides this, by connecting to the phone and proxying messages through it. Of course, that also requires implicit trust in WhatsApp Web, but it is possible. And using WhatsApp requires implicit trust in Facebook anyway, so...
- est31 8y ago
  It still requires you to run the WhatsApp phone app though. I doubt that facebook wants to require all of their users to have phones. You can reimplement WhatsApp's functionality in client side JS but then you get into deep technical problems rooted from the fact that js is, in general, ephemeral and not something permanent compared to an ios/android app. E.g. when someone logs onto facebook on a their friend's computer to check their messages you want everything to be smooth including message search but in order to provide message search, either the server needs access to the plaintext or the client needs to download the entire message history... If there's an app the client already has the entire history so that's no problem, but it is a problem with ephemeral Javascript. Another problem you run into is that Facebook can serve specifically manipulated Javascript just for you ^ TM because you are an interesting target or something. For Android/iOS this would require an app update and need to go through a third party and I haven't heard that google or apple give you the option to push a specific app to a specific device.
basch 8y ago
you could type the key into each client each time, no? isnt that how things like dashlane work? it sends the encrypted historical blob to your device, your device decodes it.
- throwawaylolx 8y ago
  I don't think such unfriendly UX would ever be considered in such a mainstream service
  - basch 8y ago
    the OPTION to start an encrypted chat, with a chat specific password?
    - instakill 8y ago
      Or storing the key in localstorage?
      - basch 8y ago
        i guess by "each time" i was being somewhat ambiguous. it could mean each login, or each install, or each time the session clears.
      - yholio 8y ago
        To enable end-to-end encryption, you need more than local storage, you need local computation using local execution of signed and reproducible code. Javascript in browsers is fundamentally not such a platform, mobile applications are - to the degree you trust Google, Apple etc.
  - shawnz 8y ago
    You already have to login with a username and password to access Facebook, unlike whatsapp where your phone is the sole key. Facebook could just construct the key at logon time based on the user's password.
NolF 8y ago
Couldn't the messages be encrypted using the user password?

yots 8y ago

Also, last time I checked Facebook still sees all the links you exchange in the conversation.

bouncing 8y ago

> if you let someone else broker the key exchange, you trust them implicitly. Sort of. Yes, they could serve you a MITM key, but it would be easily discoverable when you compare security codes in the client. And since the client is widely distributed on major app stores, it would be very risky to ship a compromised client. Ultimately key exchange is a hard problem to solve. Notice that Signal doesn't do anything that much different; Signal does the key exchange and unless you verify each user's key offline, you have to trust it. Both WhatsApp and Signal have an option to display a notice when keys change, but Signal's is on by default. Overall it's still pretty damn good. WhatsApp is perhaps the only major form of consumer communication where, by default and with no opt-out, every single chat really is fully encrypted using a widely respected protocol (libsignal). That's not nothing.

madeofpalk 8y ago
iMessage, though operating at a smaller scale than WhatsApp
- bouncing 8y ago
  Indeed! iMessage should get an honorable mention. Having lived outside of the US for a few years, sometimes I forget it exists, because here even people who both have iPhones use WhatsApp. iMessage deserves an honorable mention, but with some caveats. As I recall and quickly Googled: There have been some concerns with their security: https://www.schneier.com/blog/archives/2016/03/imessage_encryp.html https://www.schneier.com/blog/archives/2016/03/imessage_encr... https://www.pandasecurity.com/mediacenter/technology/need-know-imessage-security-flaw/ https://www.pandasecurity.com/mediacenter/technology/need-kn... https://www.tomshardware.com/news/imessage-weak-encryption-matthew-green,32466.html https://www.tomshardware.com/news/imessage-weak-encryption-m... Additionally, iMessage doesn't have any means of out-of-band key verification, so you actually have to trust Apple to faithfully exchange keys and there's no way to verify that it's done so. iMessage also tells you after a message is sent (via the color of a bubble) whether the recipient received it using iMessage. That's not very good assurance if, say, you're messaging a journalist in an authoritarian country. Will it go out over SMS or iMessage? You can find out, but even a little bit of doubt about that can have significant consequences. I'm glad iMessage does do encryption like it does, but it's no replacement for Signal and WhatsApp uses libsignal for its encryption.

crystaln 8y ago

For sure if you are using any app or OS over which you don't have complete knowledge and control, and which isn't entirely unhackable, you are trusting someone somewhere. Application companies will always be able to backdoor their apps. What e2e encryption does do is make messages nearly impossible to be intercepted in transit or on a massive scale by anyone without the cooperation of the company.

wyldfire 8y ago
> What e2e encryption does do is make messages nearly impossible to be intercepted in transit or on a massive scale by anyone without the cooperation of the company. I don't understand why you and others in this thread describe it this way. "end to end" in this description sounds a lot like "transport security" -- like what you get from TLS (https, e.g.). How is this version of "end to end" (where are the ends?) any better than TLS?
- lmm 8y ago
  > I don't understand why you and others in this thread describe it this way. "end to end" in this description sounds a lot like "transport security" -- like what you get from TLS (https, e.g.). How is this version of "end to end" (where are the ends?) any better than TLS? TLS is client-server oriented. When a messaging system uses "transport security", like Facebook Messenger, that normally means that your client's connection to Facebook's server is encrypted, but Facebook's server still has access to your message plaintext. Whereas an "end to end" encrypted system would encrypt messages on your client that are only encrypted by the person you're talking to's client. (I'm similarly skeptical about how much difference this makes in practice - I don't know what the threat model is where you trust a closed-source app and closed source google play services but don't trust the same company's servers. But it is a real distinction in behaviour)
  - wyldfire 8y ago
    You may have misunderstood my reply to mean that I don't understand what's different between TLS and end to end encryption. In fact I don't understand the difference between TLS and -- let's call it E2E' (that which might be "end to end encryption"). If E2E' permits the message broker to intercept messages, does it satisfy the conventional definition of "end to end encryption"? No, certainly not. Is it any better than TLS? No, not in my opinion. Here's what I quoted, which I believe to be E2E': > What e2e encryption does do is make messages nearly impossible to be intercepted in transit or on a massive scale by anyone without the cooperation of the company.

rafiki6 8y ago

I guess it's fair to assume that when we say "the conversation's participants" we explicitly mean everyone except the broker. I think it's important in this day and age to accept that the broker is now a conversation participant as well. Maybe we should look more into P2P messaging software.

wyldfire 8y ago
> the broker is now a conversation participant as well. I don't agree. This is the antithesis of the intent of the term "end to end encryption." Otherwise you could just use TLS to secure each of the {client->broker} connections and then you could call it "end to end".
rafiki6 8y ago
I don't see why my comment was down voted. I made a valid argument that the expectation of the broker not being privy to the conversation is a bit unreasonable and we should further explore P2P.

throwawaymath 8y ago

I think end-to-end encryption is currently undergoing a crisis of definition. Within the security and cryptography communities, implementations of secure messaging like Whatsapp and iMessage are considered to be end-to-end encrypted communications. The philosophical intention of end-to-end encryption is to enable communication through infrastructure which you do not trust. Beyond the technical considerations, different demographics have various expectations about what end-to-end encryption means. Sometimes their position is that end-to-end encryption does not exist without decentralization. Some want to have a fully federated protocol. Others believe that allowing an intermediary to broker key exchange invalidates the end-to-end confidentiality and authenticity assurances. This often leads to nitpicking about what defines end-to-end encryption which, while a useful exercise in its own right, doesn't capture the heart of the grievances at play. In many cases it would be more productive to talk more directly about expectations regarding the security and privacy of a service or protocol rather than whether or not it fulfills an underspecified set of criteria. This is to say that you can make a compelling argument that allowing a third party to broker your key exchange is insufficiently secure for you. But if you anchor that critique to whether or not the protocol satisfies end-to-end encryption, you're inviting rebuttals that don't substantially respond to what your critique is. Whether or not something satisfies end-to-end encryption is somewhat less important than whether or not you think it holistically satisfies what you consider to be strong confidentiality and authenticity assurances. If your problem is that you don't want a company like Facebook bootstrapping the key exchange for you, then you should defend that (valid) opinion by choosing a different set of criteria to work with.

feanaro 8y ago
Decentralization/federation and the existence of third-party brokers don't really come into play here. What is required is a. a cryptographically secure protocol b. an UI that is strict about checking that the keys and signatures match and is loud about notifying the user when they don't c. an open source client
- throwawaymath 8y ago
  An open source client is not required for end-to-end encryption. Do you see what I'm getting at? We're quibbling about a technically precise definition instead of what you'd like to see in a secure messaging application.

FrankDixon 8y ago

to me all this end-to-end business sounds too much like marketing. As long as you have to use the clients provided by facebook, it doesn't matter that the chats are end-to-end encrypted. Facebook controls the clients and as such can do whatever it likes with your chats (or whatever you agreed to)

throwawaymath 8y ago
End-to-end encryption is about decomposing trusted parties and compartmentalizing untrusted infrastructure. There are meaningful differences between end-to-end encryption and server-side encryption. These differences are entirely orthogonal to the question of whether or not you can verify the client or the server. This is what I was getting at in my other comment. If you’re going to reject end-to-end encryption because you can’t verify the client, you’re looking at a very different set of criteria to establish the confidentiality and authenticity assurances you want. In particular, you are at a point where it’s difficult to establish a secure channel unless you’re using a fully decentralized, federated protocol with a server you stood up yourself.
- megous 8y ago
  Yes, that's why you need independently developed and independently distributed client software. Otherwise there's no meaningful compartmentalization. The parent poster is not rejecting end-to-end crypto itself, but how it's typically done. (on a locked phone you don't really control in an autoupdating app you don't control at all) Web based end to end encryption is even more ridiculous (say mega.nz for example), because then it's even more trivial to distribute different code to differnet users.
  - throwawaymath 8y ago
    There is meaningful compartmentalization without independent distribution and development. That point was the entire basis of my comment.

vorticalbox 8y ago

You can enable a notification in the settings when a person keys changes.

fortenforge 8y ago

What application would you say has "real" e2e encryption? Signal and all the other apps have exactly the same problem right? If you don't compare your keys offline, you're always at risk for this attack. You can't build cryptography out of sand.

rhizome 8y ago
At the very least, Signal notifies on rekeying and in both the desktop and Android versions it doesn't appear to be changeable.
- indigo945 8y ago
  WhatsApp also notifies on rekeying. A yellow message is shown warning that "your conversation partner's security codes have changed" or something of the sort.
  - kikoreis 8y ago
    It's an option. And it's disabled by default.
mach5 8y ago
keybase does! https://keybase.io/ https://keybase.io/
- indigo945 8y ago
  How does keybase do key exchanges?
- lucb1e 8y ago
  You're saying at Keybase you don't have to compare your fingerprints out of band?
  - 0xb100db1ade 8y ago
    Correct. Key verification is done by looking at signatures on a given user's linked social networks / websites etc

DonbunEf7 8y ago

I have a hard time believing Zuckerberg would purposely exclude himself from the conversation. You know what's bizarre to me? Most US states are either one party consent or 2 party consent states. Meaning to record a conversation, at least one party must consent to the conversation being recorded. So how does this not apply at all to private conversations online?