7 ms·

> 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 discoverab

> 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.
  - tome 8y ago
    > you actually have to trust Facebook Do you mean "you have to trust Apple"? I don't see what Facebook has to do with iMessage. [EDIT: Now corrected above. Thanks!]
    - bouncing 8y ago
      Think-o.
  - deca6cda37d0 8y ago
    The colour of the send button tells you if it’s an iMessage or a text message.
    - reaperducer 8y ago
      Yes, and no. If you send a message to someone you've most recently conversed with on iMessage, it will be blue. But if iMessage can't deliver the message, it will fall back to using text messages. I believe on the next attempt, the button will be green, but I don't have a way to test that right now.
      - briandear 8y ago
        No, it will ask you if you want to send as text. It doesn’t do it without you explicitly allowing it.
        reaperducer 8y ago
        As recently as last weekend, I had it go through as green instead of blue without asking because the recipient was in a no-data area. Perhaps because I'd previously approved green messages for that person.
  - polskibus 8y ago
    Didn't China receive special access to iMessage from Apple?
- deleted 8y ago
  [deleted]
firebird84 8y ago
Just clarifying something you alluded to: Signal claims that Whatsapp actually uses the same protocol, so naturally the key exchange is very similar.
wyldfire 8y ago
> Yes, they could serve you a MITM key, but it would be easily discoverable Like a lot of things it boils down to your threat model. If the broker or a state are your adversary, it wouldn't need to be a general design feature to behave this way but it could instead target you at the time of key exchange. Not an implausible scenario for reporters and their sources, e.g. Those folks are especially vulnerable because they might be led to believe claims of "end to end encryption". Put that together with those default settings and interception and impersonation can happen right under your nose.
feanaro 8y ago
> 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. Let's not forget Signal is FOSS and has reproducible builds (https://signal.org/blog/reproducible-android/ https://signal.org/blog/reproducible-android/). This makes it far easier to trust its verification code.
- crankylinuxuser 8y ago
  Yes, signal is better than FB or sms.. But the whole requiring phone number puts a nail in it on my end. So Signal can learn who talks with whom via requests going through their LDAP-like server. They can get an idea how long calls are, and if it was a vid or audio call. They know the times of communication. You know, they can see the metadata. When's the last time we had problems with metadata? The POTS network? Yep. And you're indeed right the client has reproducible builds. But the server side certainly doesn't. And we have no way to ascertain that.
  - feanaro 8y ago
    > You know, they can see the metadata. When's the last time we had problems with metadata? The POTS network? Yep. Yes, metadata is a problem, particularly with calls. However, Signal recently added the sealed sender (https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/) feature which makes the server blind to who the sender of a message is. > And you're indeed right the client has reproducible builds. But the server side certainly doesn't. That's true, but the server side is much less important when it comes to cryptographic assurances. Signal is definitely not a panacea, but by many counts it's better than anything else that currently exists and has any semblance to something a typical user can use.
    - Forbo 8y ago
      For what it's worth, they don't retain any of that metadata. This has been tested in court: > We’ve designed the Signal service to minimize the data we retain about Signal users, so the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user’s connectivity to the Signal service. https://signal.org/bigbrother/eastern-virginia-grand-jury/ https://signal.org/bigbrother/eastern-virginia-grand-jury/ This was even before sealed sender, so if anything my confidence in the Signal Foundation has only increased.
mtgx 8y ago
> Yes, they could serve you a MITM key, but it would be easily discoverable when you compare security codes in the client. Who does that for every conversation? Or even once per week/contact?
- exacube 8y ago
  security researchers
  - vinay_ys 8y ago
    So put them in a cohort and treat them differently than the rest of the users? Personalised key exchange? Possibilites are endless. If you don't trust the closed source operator here, then that end to end encryption should mean nothing for you.
- bronco21016 8y ago
  Or use a client like Signal that tells you when the key has changed.
kovek 8y ago
I'm confused what does the client have to do with this. My understanding of these end to end encryption models is with public/private keys. You (Facebook, Whatsapp, or the user) generate a private and a matching public key. You distribute the pair of keys to the user who'd like to do communication. The user should not share their private key, not even to Facebook or Whatsapp. The user publishes his public key so other can encrypt messages using the user's public key and send their messages to said user. The user then uses the private key to decrypt the encrypted message. If Facebook keeps a copy of the private key, then they could read the encdypted message. Maybe the client itself is generating the keypair. In this case, the only issue I can see is the following: when the user wants to communicate with a friend, how can they be sure that the profile they are sending messages to (as displayed by their user interface and communicated by Facebook or Whatsapp or the friend's server) actually do belong to their friend? I'm confused what you were talkimg about, with the client build possibly being a trojan
- indigo945 8y ago
  >Maybe the client itself is generating the keypair. In this case, the only issue I can see is the following: when the user wants to communicate with a friend, how can they be sure that the profile they are sending messages to (as displayed by their user interface and communicated by Facebook or Whatsapp or the friend's server) actually do belong to their friend? That's exactly the point though, how can they be sure in the event that their client (on the author's side) is a trojan? If the "author" client is deliberately compromised, there is no longer any reasonable means of ensuring that the public key the author uses to encrypt the messages is actually equal to the public key the recipient published. Of course, this point is very much riddled with paranoia: it is exceedingly unlikely that the WhatsApp client deliberately contains such a trojan, especially since there are much easier ways of gaining access to user's messages (such as compromising their firmware with some form of rootkit, possibly installed via the baseband, and then simply sending copies of the local message cache to the NSA).
- nnd 8y ago
  The only way to know for sure is to verify your friend's signature in offline.
speeq 8y ago
How is WhatsApp using libsignal without being obligated to disclose their source code - as it's licensed under GPL?
- groestl 8y ago
  If WhatsApp uses a version of libsignal whose copyright is solely in the hands of Open Whisper Systems, OWS can have a separate deal with WhatsApp which does not involve the GPL. AFAIK, this is already done to get Signal into the App Store (IANAL though).
  - StudentStuff 8y ago
    Moxie was brought on as a contractor at WhatsApp iirc, the code wasn't just purchased. While WhatsApp uses the same cryptographic architecture its likely they didn't just drop in libsignal (as libsignal is set up to tie into Signal's servers, rather than just be an encryption library like OMEMO or olm). If your looking to build software that integrates with Signal, then libsignal is great (having built a few things with it).

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.
- tome 8y ago
  > you actually have to trust Facebook Do you mean "you have to trust Apple"? I don't see what Facebook has to do with iMessage. [EDIT: Now corrected above. Thanks!]
  - bouncing 8y ago
    Think-o.
- deca6cda37d0 8y ago
  The colour of the send button tells you if it’s an iMessage or a text message.
  - reaperducer 8y ago
    Yes, and no. If you send a message to someone you've most recently conversed with on iMessage, it will be blue. But if iMessage can't deliver the message, it will fall back to using text messages. I believe on the next attempt, the button will be green, but I don't have a way to test that right now.
    - briandear 8y ago
      No, it will ask you if you want to send as text. It doesn’t do it without you explicitly allowing it.
      - reaperducer 8y ago
        As recently as last weekend, I had it go through as green instead of blue without asking because the recipient was in a no-data area. Perhaps because I'd previously approved green messages for that person.
- polskibus 8y ago
  Didn't China receive special access to iMessage from Apple?
deleted 8y ago
[deleted]

firebird84 8y ago

Just clarifying something you alluded to: Signal claims that Whatsapp actually uses the same protocol, so naturally the key exchange is very similar.

wyldfire 8y ago

> Yes, they could serve you a MITM key, but it would be easily discoverable Like a lot of things it boils down to your threat model. If the broker or a state are your adversary, it wouldn't need to be a general design feature to behave this way but it could instead target you at the time of key exchange. Not an implausible scenario for reporters and their sources, e.g. Those folks are especially vulnerable because they might be led to believe claims of "end to end encryption". Put that together with those default settings and interception and impersonation can happen right under your nose.

feanaro 8y ago

> 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. Let's not forget Signal is FOSS and has reproducible builds (https://signal.org/blog/reproducible-android/ https://signal.org/blog/reproducible-android/). This makes it far easier to trust its verification code.

crankylinuxuser 8y ago
Yes, signal is better than FB or sms.. But the whole requiring phone number puts a nail in it on my end. So Signal can learn who talks with whom via requests going through their LDAP-like server. They can get an idea how long calls are, and if it was a vid or audio call. They know the times of communication. You know, they can see the metadata. When's the last time we had problems with metadata? The POTS network? Yep. And you're indeed right the client has reproducible builds. But the server side certainly doesn't. And we have no way to ascertain that.
- feanaro 8y ago
  > You know, they can see the metadata. When's the last time we had problems with metadata? The POTS network? Yep. Yes, metadata is a problem, particularly with calls. However, Signal recently added the sealed sender (https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/) feature which makes the server blind to who the sender of a message is. > And you're indeed right the client has reproducible builds. But the server side certainly doesn't. That's true, but the server side is much less important when it comes to cryptographic assurances. Signal is definitely not a panacea, but by many counts it's better than anything else that currently exists and has any semblance to something a typical user can use.
  - Forbo 8y ago
    For what it's worth, they don't retain any of that metadata. This has been tested in court: > We’ve designed the Signal service to minimize the data we retain about Signal users, so the only information we can produce in response to a request like this is the date and time a user registered with Signal and the last date of a user’s connectivity to the Signal service. https://signal.org/bigbrother/eastern-virginia-grand-jury/ https://signal.org/bigbrother/eastern-virginia-grand-jury/ This was even before sealed sender, so if anything my confidence in the Signal Foundation has only increased.

mtgx 8y ago

> Yes, they could serve you a MITM key, but it would be easily discoverable when you compare security codes in the client. Who does that for every conversation? Or even once per week/contact?

exacube 8y ago
security researchers
- vinay_ys 8y ago
  So put them in a cohort and treat them differently than the rest of the users? Personalised key exchange? Possibilites are endless. If you don't trust the closed source operator here, then that end to end encryption should mean nothing for you.
bronco21016 8y ago
Or use a client like Signal that tells you when the key has changed.

kovek 8y ago

I'm confused what does the client have to do with this. My understanding of these end to end encryption models is with public/private keys. You (Facebook, Whatsapp, or the user) generate a private and a matching public key. You distribute the pair of keys to the user who'd like to do communication. The user should not share their private key, not even to Facebook or Whatsapp. The user publishes his public key so other can encrypt messages using the user's public key and send their messages to said user. The user then uses the private key to decrypt the encrypted message. If Facebook keeps a copy of the private key, then they could read the encdypted message. Maybe the client itself is generating the keypair. In this case, the only issue I can see is the following: when the user wants to communicate with a friend, how can they be sure that the profile they are sending messages to (as displayed by their user interface and communicated by Facebook or Whatsapp or the friend's server) actually do belong to their friend? I'm confused what you were talkimg about, with the client build possibly being a trojan

indigo945 8y ago
>Maybe the client itself is generating the keypair. In this case, the only issue I can see is the following: when the user wants to communicate with a friend, how can they be sure that the profile they are sending messages to (as displayed by their user interface and communicated by Facebook or Whatsapp or the friend's server) actually do belong to their friend? That's exactly the point though, how can they be sure in the event that their client (on the author's side) is a trojan? If the "author" client is deliberately compromised, there is no longer any reasonable means of ensuring that the public key the author uses to encrypt the messages is actually equal to the public key the recipient published. Of course, this point is very much riddled with paranoia: it is exceedingly unlikely that the WhatsApp client deliberately contains such a trojan, especially since there are much easier ways of gaining access to user's messages (such as compromising their firmware with some form of rootkit, possibly installed via the baseband, and then simply sending copies of the local message cache to the NSA).
nnd 8y ago
The only way to know for sure is to verify your friend's signature in offline.

speeq 8y ago

How is WhatsApp using libsignal without being obligated to disclose their source code - as it's licensed under GPL?

groestl 8y ago
If WhatsApp uses a version of libsignal whose copyright is solely in the hands of Open Whisper Systems, OWS can have a separate deal with WhatsApp which does not involve the GPL. AFAIK, this is already done to get Signal into the App Store (IANAL though).
- StudentStuff 8y ago
  Moxie was brought on as a contractor at WhatsApp iirc, the code wasn't just purchased. While WhatsApp uses the same cryptographic architecture its likely they didn't just drop in libsignal (as libsignal is set up to tie into Signal's servers, rather than just be an encryption library like OMEMO or olm). If your looking to build software that integrates with Signal, then libsignal is great (having built a few things with it).