
WhatsApp's Signal Protocol integration is now complete - piquadrat
https://whispersystems.org/blog/whatsapp-complete/
======
mike_hearn
This is really excellent. A few thoughts:

1) They seem to have replaced TLS/SSL between client and server with "Noise
Pipes". Based on a couple of minutes Googling this seems to be a brand new
one-man protocol from Trevor Perrin (the same guy who did Axoltl on which
Signal is based). At least, I'd never heard of it. I wonder if this is the
first inkling of a post-TLS future?

[http://noiseprotocol.org/noise.html](http://noiseprotocol.org/noise.html)

2) It's a shame to see key words be killed off by internationalisation
concerns. 12 words seems so much more friendly, at least to English speakers,
than a 50 digit number. In practice I doubt any non-trivial numbers of people
will ever compare codes by reading out such a number. I hope further research
here can develop better replacements for encoding short binary strings in i18n
friendly ways (perhaps with icons instead of specific words? if you don't
speak a common language with your chat partner then the app is useless
anyway).

3) What's the next step? My feeling is that the next step is securing the
build and distribution pipeline. WhatsApp could partner with security firms
around the world, like Kaspersky Lab in Moscow, perhaps one in Germany and
another in Iran, to make it harder for the software to be forcibly backdoored
by a single decision of a single government representative. This would require
splitting the RSA signing keys used by the app stores. I have some code in my
inbox that claims it can do this (it's written by some academics and I
obtained it after a bit of a runaround) but I never found the time to play
with it.

Of course, getting a bunch of security firms to sign off on every update, no
matter how trivial that update is, might prove politically difficult inside
Facebook. If mobile platforms supported in-app sandboxing better then the app
could slowly be refactored to be more like Chrome, where the base layer
doesn't trust the upper layers. Those upper layers wouldn't have access to key
material and could then be updated more freely than the higher privileged
components.

~~~
moxie
> They seem to have replaced TLS/SSL between client and server with "Noise
> Pipes".

WhatsApp was already using a custom protocol instead of TLS. We worked with
them to transition over to Noise Pipes, which has some advantages over what
they were doing before. Also, we've renamed Axolotl to Signal Protocol:
[https://whispersystems.org/blog/signal-inside-and-
out/](https://whispersystems.org/blog/signal-inside-and-out/)

~~~
tptacek
It is _killing_ me that you didn't rename Signal to Axolotl.

~~~
aw3c2
Why?

"Axolotl" at least has seriously pronunciation issues so I am glad it is not
used "user-side".

~~~
tptacek
For my part: because "Axolotl" is one of the most widely name-dropped terms in
hipster cryptography, and because it's been adopted by other projects, and
because it's distinctive, and because they basically own the term. In a
stroke, everyone doing secure key ratchets would have been using _their
product_.

It's also just a cool name.

~~~
garrettr_
I always liked "Axolotol" because axolotols are a type of salamander with the
amazing ability to regenerate parts of their bodies (including their brains!),
and the Axolotol protocol, like OTR, is "self-healing", meaning it's capable
of recovering from a compromised session key
([https://whispersystems.org/blog/advanced-
ratcheting/](https://whispersystems.org/blog/advanced-ratcheting/)).

~~~
david-given
Axolotls are also cool because they're not really a species in their own right
--- they're actually just the juvenile form of a salamander. But they can
breed while in their juvenile form! It's as if tadpoles could lay eggs without
having to turn into frogs first.

In fact, axolotls only metamorphose into salamanders if triggered by the
external environment. If you don't stimulate them in the right way, they stay
axolotls. For a long time they were thought of as two different types of
creature completely.

There's a story of one of the very early researchers looking at his vivarium
one day and discovering that it was now full of salamanders rather than the
axolotls he was expecting. I would love to have heard the conversation...

~~~
seivan
Basically like a Pokemon.

------
pilif
What the article fails to mention:

1) I would assume Facebook still gets unencrypted access to my address book
for use with their shadow profiles

2) We have zero control over what key the client encrypts the messages for. Is
it only the other peer's phone? Or is it for the peer's phone plus Facebook
for analysis of the messages?

Especially 2) is of some concern to me (against 1 I can't protect myself
anyways because if people add me to their address books I'm screwed anyways).
From that perspective, I'm still inclined to trust apple's iMessage a bit more
especially after recent events.

The only safe solution right now is to compile your own signal client and use
that, of course at the cost of reach because nobody else is on Signal.

WhatsApp might be a good compromise at least for only semi-important messages:
The probability that any of your contacts has WhatsApp is much, much higher
than the probability of them having Signal running. On the other hand,
whatever you're sending over WhatsApp is likely going to be used by FB (and
then possibly handed out to governments and/or stolen by attackers).

~~~
tptacek
I think this is a reasonable analysis. I would refine it this way (examples
are only for illustrative purposes):

Tier 1 secure messengers: all possible tradeoffs in favor of security made;
use for worst-case adversaries:

 _\- Signal /TextSecure \- Pond \- PGP† \- OTR_

Tier 2 secure messengers: serious secure messaging protocols that make some
tradeoffs in favor of adoption and usability; use for normal messages of low
sensitivity:

 _\- WhatsApp \- iMessage_

Tier 3 secure messengers: secure messaging protocols with flaws, limited
cryptanalysis, only content-controlled browser clients, &c

 _\- Redacted to avoid flamewars._

Everything else: insecure; use only to bootstrap conversations to a Tier 2
protocol (knowing that if you're a state-level target, you're exposed even
after you "upgrade")

 _\- Google Talk \- Facebook Messenger \- AIM_

I think WhatsApp would like to be a tier 1 secure messenger (they'd be the
first mainstream tier 1 secure messenger!) and they have a shot at being that,
but they're probably some years away from it.

† _(I know PGP and OTR are cryptographically limited compared to Signal
Protocol, but from an OPSEC perspective they 're still a tier above
iMessage.)_

~~~
tveita
I would place Signal in the same tier as WhatsApp here (Tier 2). They both
upload your contacts to an intermediate server that gives you their public
key, which you can optionally verify afterwards.

This means a malicious server could both store away your contacts and try to
MITM you, risking detection if you do verify your fingerprint with the other
party.

A messenger that really did "all possible tradeoffs in favor of security"
would force you to verify the recipient, either in person or via a web of
trust. I think not doing that is a perfectly acceptable tradeoff to protect 1
billion users from passive mass surveillance.

These are all UI issues though, the Signal protocol seems solid, and I'll be
glad to see it used everywhere. Hopefully we will get clients that you could
recommend to a journalist or lawyer and have confidence that they will be able
to use it for secure authenticated communication.

~~~
tptacek
That's something that's at least somewhat true of OTR and PGP too, in their
normal use, and in all three cases if you're serious about OPSEC you can
completely mitigate the problem. So in my evaluation, Signal's a tier 1
option, and WhatsApp is tier 2.

Reasonable people can disagree, of course.

I hope it's obvious that, since OTR is in tier 1, these tiers aren't an
analysis of how much _I like_ different messengers. :)

~~~
tveita
> That's something that's at least somewhat true of OTR and PGP too

Well, OTR is just the protocol, implementations vary in how well they make you
authenticate your conversation partner. And PGP will whine at you a lot if you
haven't marked a key as trusted. But somewhat agreed. A bad UI can ruin the
security of otherwise solid crypto.

I just don't see how the security of Signal and WhatsApp are different.
Assuming for a moment (very optimistically) that the user verifies the
fingerprint and enables the alert for changed keys, they are using the same
protocol with the same guarantees.

Are you factoring in some level of trust in their ability to write a secure
client or run secure servers?

~~~
Joof
Its probably only a half-step up, but signal's client (and server?) are open
source. You could compile your own to avoid problems with the binary blob
being different. Maybe you could run your own server to dish out keys, but
that may be a stretch.

------
owenversteeg
This is insanely cool. For everyone (very rightfully) worried about the
PATRIOT act, the NSA, etc., etc. this is absolutely huge.

One BILLION people just got their messages encrypted. Facebook was under no
obligation to do this; for the vast majority of tech history the messages sent
by 99% of people were very insecure, and when the tech giants responsible were
asked their response was "ehh". This suddenly cuts into a huge portion of
that. Pretty much everyone with a mobile phone in Europe or South America, as
well as large parts of Asia, suddenly now has completely encrypted messages.

Kudos to Whatsapp for this fantastic move.

On a related note, if anyone is inspired by this announcement to start using
encryption in other parts of their life, I have a handful of Keybase invites
available (to bypass the 25k+ waiting list.) Keybase's security depends on
lots of people tracking other people, so only ask for one if you'll track
other people. I see too many people that make an account and nobody ever
tracks them/they don't track anyone. My email's in my profile.

~~~
Chris2048
> For everyone worried about the PATRIOT act, the NSA

Does this actually protect you? If data goes through US FB servers, don't the
NSA have access?

~~~
Johnny_Brahms
To the metadata and ciphertext, sure. Still better than metadata AND data.

~~~
Chris2048
Where are the keys generated & stored? Is the APP openly audited?

------
envy2
WhatsApp have published further details for users[1], as well as a technical
whitepaper[2] explaining the implementation. There's also a blog post[3].

[1]: [https://www.whatsapp.com/security/](https://www.whatsapp.com/security/)

[2]: [https://www.whatsapp.com/security/WhatsApp-Security-
Whitepap...](https://www.whatsapp.com/security/WhatsApp-Security-
Whitepaper.pdf)

[3]: [https://blog.whatsapp.com/10000618/End-to-end-
encryption](https://blog.whatsapp.com/10000618/End-to-end-encryption)

~~~
mike_hearn
That last blog post is clearly written by Jan Koum, as it talks about his past
in the Soviet Union. But his name doesn't appear anywhere on the blog post and
if you didn't know that odd bit of trivia, it'd be completely confusing - who
the heck is talking? Some random employee?

They need to add the name and job title of the blog posts author to the
bottom.

~~~
envy2
It's now signed "Jan and Brian."

~~~
mike_hearn
That's great. I wonder if it's because they saw my post or if they realised
the issue themselves.

------
mjs
Is there any reasonable way to verify that end-to-end encryption is actually
being used, and used correctly? From a user's point of view the app looks and
works exactly the same as before, except for the addition of a QR code which
could be doing anything.

~~~
mike_hearn
Define 'reasonable'.

Essentially, no. You have to trust that the app is really doing what it claims
to be doing.

If it were open source, would it be different? Maybe. Signal Messenger is open
source and the Android build is reproducible. However, the way you reproduce
it is to run a Docker image, so that isn't really meaningful unless you audit
the code that's used to build it. And then audit the code of the app itself.
Fortunately, the Android app is written in Java, so you can easily do static
analysis to narrow down what code needs to be audited. Unfortunately, it also
includes native code that can reach into arbitrary parts of the heap if it
were to try and steal keys. So you'd have to audit all of that. And then keep
up with all the changes. Which you aren't going to do.

Even if you did all of that, at some point the naughty thought will occur to
you that all your effort can be undone by an operating system update that
contains more than it claims to. And then you'll give up.

In practice, it's impossible to really verify anything about how our modern
computers work: there are too many people and companies who can silently
access key material or just fool us in other ways.

So it's best to understand this work in context - this is not about allowing
you to use WhatsApp if your threat model is that WhatsApp is entirely
malicious. It's about discouraging governments from going to WhatsApp and
saying "you need to give us all your data" because it creates the same
situation Apple has: WhatsApp would need to write _new software_ to undo the
encryption, and that can be legally argued to be "compelled speech", and thus
it can fall outside the legal powers granted under wiretap orders.

~~~
visarga
But can we still be sure of our privacy if we combine two or more such semi-
secure systems? TOR does such a thing with the Onion Routing protocol by using
intermediaries.

~~~
mike_hearn
No. There is no way to be completely sure of your privacy in any context when
using modern computers, it simply isn't a problem that can be solved with
technical tricks.

Consider all the work I listed above. Imagine you actually did it. Great. But
... you're using WhatsApp to communicate with someone else. Did they do the
same work? No? What if their device received a different binary to yours?

You can't even solve this with clever auditing frameworks because then you're
just shifting the trust to whoever writes and distributes the auditing tools.

That's why it's so important to understand that you cannot solve political
problems with cryptography. At most, you can reconfigure the set of people you
need to trust (hopefully by making it smaller). But if those people can be
forced to act by a political entity, then no crypto will save you.

------
nnnnnn
Without whatsapp being open source, how do we know for sure that Facebook is
not somehow storing or reading our messages?

As good as this sounds on paper, I hesitate to trust Facebook to transmit my
data without wanting to peek a bit. I currently use both Whatsapp and Signal
and will probably continue to do the same unless there is a way for users to
verify Facebook doesn't keep a copy.

~~~
tptacek
Closed source software isn't impenetrable. The idea that you need source code
to evaluate security claims is mostly a meme from the 1990s.

~~~
dest
Taking the example of Skype, the hardening/on-the-fly decryption techniques
used in the binary made the reverse engineering very difficult [0]. Difficult
to reliably audit such software. Don't know about Whatsapp though.

[0] [http://www.oklabs.net/skype-reverse-engineering-the-long-
jou...](http://www.oklabs.net/skype-reverse-engineering-the-long-journey/)

~~~
tptacek
That was true in the case of Skype (which was eventually reversed), but it is
not true here.

~~~
dest
Maybe it is feasible, but at the very least I would wait for someone to
reverse engineer it and publicly publish its findings. I do not have the
skills to do that.

Moreover, if reverse engineering is so easy, why not open-source it from the
beginning?

~~~
tptacek
If you don't have the skills to do basic verification of a non-obfuscated
binary, you don't have the skills to verify an encrypted messaging protocol
implementation from source either: the latter task is _harder_ than the
former!

I think the misconception some people here have about the necessity of source
code is born out of the idea that a cryptographic backdoor would look
something like a mysterious HTTP POST of your key or plaintext to some random
endpoint (that POST, by the way, would be trivial to spot in the binary; you
wouldn't even need to read assembly).

But real cryptographic backdoors can be extremely difficult to spot. A
cryptographic algorithm that uses signatures, for instance, can be fatally
compromised by breaking signatures (see: TLS). An injected cryptographic flaw
that breaks signatures can be as simple as biasing a single-digit number of
bits in a nonce; a bias can be as subtle as generating one less byte of
randomness than the protocol requires.

~~~
codys
> If you don't have the skills to do basic verification of a non-obfuscated
> binary, you don't have the skills to verify an encrypted messaging protocol
> implementation from source either: the latter task is harder than the
> former!

Those aren't quite the same skill though. Some folks could have the skills to
verify protocols from source, but not the skills to work with a non-obfuscated
binary. Task 'A' being harder than task 'B' doesn't mean that everyone who can
do 'A' (harder task) is capable of 'B (easier). Nor does the inverse follow at
all.

If we admit that doing basic (non-messaging protocol impl) verification on a
binary is difficult and doing messaging protocol impl verification is also
difficult, it seems reasonable to presume that doing both will take more time,
work, and as a result, allow for more errors in verification.

Essentially, verifying impls without source code is more difficult/time
consuming/error prone than verifying ones with source code.

Of course, they could give someone the source code to verify without making it
open source. But that requires that one trust this other party, selected by
folks who have an interested in their protocol being reported as secure
(whether it is or not).

The goal when folks are looking for freely available source code is to
eliminate some of those needs for trust (by allowing a greater number of
verifiers) and eliminate some of the conflict of interest (by removing some
control the interested party has).

Sure, closed source bits that promise to be good and that we can (potentially)
look at are OK. But having source code for them is still better.

~~~
kasey_junk
I think the argument (one I'm not expert to make) is that the source may or
may not be helpful to someone who is competent enough to validate a encrypted
message application, but it is not what you need to verify.

You _must_ verify the binary because you cannot trust the source, so it is a
basic skill of anyone who has the competency to validate an encrypted message
application.

Now, its possible, that the source along with repeatable builds make verifying
the binary easier for someone with the skills necessary, but even with those
things, they still have to verify the binary.

~~~
tptacek
Yep. I _don 't_ think source is a bad thing! It's good to have, but it isn't
the predicate people on this thread were saying it was.

------
levelpublish
Question for me is still around iCloud backups. Per
[http://www.popsci.com/whatsapp-now-encrypts-all-messaging-
fo...](http://www.popsci.com/whatsapp-now-encrypts-all-messaging-for-its-
billion-users):

> However, WhatsApp on iOS still backs up chat logs to iCloud, and despite any
> effort by Facebook, those could be given to a law enforcement agency. It's
> not known whether the backups are encrypted, but we've reached out to Open
> Whisper Systems and will update with any new information.

Apple stores iMessage backups unencrypted and hands them out when given a
lawful request (per [https://thehackernews.com/2016/01/apple-icloud-
imessages.htm...](https://thehackernews.com/2016/01/apple-icloud-
imessages.html\);) WhatsApp needs to store encrypted backups to prevent this
attack.

------
sauere
Does this include file transfers, if so, how?

Curious because when sending a .webm video from an Android device to a iOS
device, the video file was transcoded on WhatsApp servers and then delivered
to the iOS device as H264/mp4 (since iOS can not play .webm files)

This should no longer be working.

~~~
epimenov
The whitepaper ([https://www.whatsapp.com/security/WhatsApp-Security-
Whitepap...](https://www.whatsapp.com/security/WhatsApp-Security-
Whitepaper.pdf)) claims that the attachments of any type are encrypted

------
ngrilly
Excellent! 3 questions:

\- What if the government forces WhatsApp to write and push a targeted
software update in order to compromise the end-to-end encryption (I'm of
course thinking of the FBI vs Apple case)? Is there a way for the user to be
notified?

\- Does WhatsApp Auto Backup encrypt messages before sending them to Google
Drive or iCloud?

\- Would it be possible for WhatsApp Web to rely on backend servers storing an
encrypted version of messages, instead of relying on a connection to the
user's phone, and still be able to perform keyword search over the encrypted
messages with something like github.com/strikeout/mylar?

~~~
hollander
> \- Does WhatsApp Auto Backup encrypt messages before sending them to Google
> Drive or iCloud?

So you make a backup and loose the phone. What about the key? Is that gone
too? Without it, encrypted backup is useless. How do you backup the key? You
and me maybe will manage to do this, but what about grandma and all those
people without anybody close who knows about this?

~~~
bad_user
The decryption key you're talking about can be a simple password. For
symmetric encryption (e.g. AES-256) even a simple password would be secure
enough, while something like a 24 chars password would be unbreakable.

~~~
Ar-Curunir
No, not really. Passwords are terribly low entropy, and so having a common
password is not a solution, at least without using some sort of KDF or such.

------
StavrosK
I came here apprehensive because you need UI support for this to work, but
reading the article I was pleasantly surprised to see that they implemented
all the verification and other bits to make this reasonably visibly secure.

Great job from everyone, I'm glad WhatsApp has done this. I look forward to
these features on my device.

------
greenspot
Great news. I'm just wondering why Facebook/Zuck is doing this. Is he fearing
the competition–all the other E2E messengers out there?

I'm asking because I could imagine that Whatsapp might get banned in some
countries soon (as recently happened in Brazil) and thus, lose market share.

~~~
teaneedz
I also wonder how Facebook will monetize WhatsApp with e2e now.

~~~
dave2000
They'll monetize Facebook with the phone numbers they get from WhatsApp users.

~~~
teaneedz
That's kind of what I was fearing. Would love to see an official response from
Moxie on the meta and contact data handling of WhatsApp's implementation.

~~~
dave2000
This is presumably why Facebook bought it in the first place, though. They
don't need to see anyone's message content for this. They get all the info
they need the first time you use it; confirming phone number 123-456-7890
belongs to person@domain.com, so they can tie together your facebook usage
with whatever customer surveys, browsing etc you've done. I don't see this as
remotely altered by the recent encryption work, other than the latter will
entice more people to use the app.

~~~
teaneedz
And I think that's really the messaging that needs to have some PR light shed
upon. Facebook has access to the meta and contact data (confirmation, Moxie?).
For all the hoopla over WhatsApp E2E crypto, users shouldn't forget that they
may be handing over phone number, contact data and other meta to the largest
ad-tech platform with a real name policy.

------
defiancedigital
I'm looking at libaxolotl-c. I'm a little bit disturbed about perfect
forward/future secrecy. Perfect forward secrecy ensure that a session key
cannot be compromised if a long-term key is compromised in future. With
something like OTR even if a session key is compromised at n, session key at
n-1 or n+1 will not be compromised. Here, we got perfect forward/future
secrecy.

If i take a look at axolotl, in scenario _Alice send message to bob when Bob
is offline_ :

(1) , (2)

MK = HMAC-HASH(CKs, "0") // (3)

msg = Enc(HKs, Ns || PNs || DHRs) || Enc(MK, plaintext)

Ns = Ns + 1

CKs = HMAC-HASH(CKs, "1") // (4)

return msg

We can see that Alice re-use CKs to get a new symmetric key. So if an attacker
get CKs(n) he could easily compute CKs(n+1) CKs is not a long term key, but we
cannot honestly call this _perfect_ futur secrecy... One more thing, if I
remember correctly, according of perfect forward secrecy definition, an
implementation must NOT re-use previous session key to derive a new one ...

I'm wrong ?

(1) Quoted from
[https://github.com/trevp/axolotl/wiki](https://github.com/trevp/axolotl/wiki)

(2) see session_cipher_get_or_create_message_keys
([https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...](https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5accaf207aa51fbf83a7d2cd389c2bd24ad/src/session_cipher.c#L646))

(3) i think we should read MK = HKDF(HMAC-HASH(CKs, 0x00) see
ratchet_chain_key_get_message_keys
([https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...](https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5accaf207aa51fbf83a7d2cd389c2bd24ad/src/ratchet.c#L162))

(4) i think we should read MK = HMAC-HASH(CKs, 0x02) see
ratchet_chain_key_create_next
([https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5ac...](https://github.com/WhisperSystems/libaxolotl-c/blob/0640b5accaf207aa51fbf83a7d2cd389c2bd24ad/src/ratchet.c#L227))

~~~
ikawe
"Perfect forward secrecy" requires synchronous key exchange. The compromise
that signal protocol makes is for forward secrecy to "eventually repair"
itself while in the meanwhile a limited number of messages are potentially
vulnerable. That is one of the novel feature of the protocol and it is what
allows for async communication without some central server doing all the key
mgmt (central key mgmt doesn't have this problem because it's actually
synchronous).

I am not a cryptographer.

~~~
caf
"Eventual forward secrecy"?

------
wodenokoto
Does this mean that WhatsApp can talk to Signal Private Messenger app?

~~~
nickik
No. Signal would probebly like to add Federation as a feature but they have
not done so (yet?). So even if Whatsapp would be down to do it, what I don't
think, then their would still be a technical issue.

Actor is a messanger that seems to focus on federation and they want to use
Singal Protocol as well. So maybe they will devlop software for that. However
their is still the issue if Whatsapp would want to do that.

~~~
muppetman
It does support federation - for a while there Cyanogenmod ran their own
Signal (then called TextSecure) server and built it into the Cyanogenmod
source.

It supported federation with Signal. But they removed it as the hassle of
supporting the server was hard, the code was outdated and everyone agreed if
you wanted that level of security, just install Signal yourself.

~~~
nickik
So, yeah, they had federation.

That seemed to be a bit hacky, not proper federation, it was not designed to
scale. Maybe Im wrong, I would like to hear somebody that knows more.

~~~
Spakman
I would really, really like to hear more about federation in Signal too. They
used to mention that it was planned, but that was a while ago now.

------
lauritz
Okay, first off: This is great. The most popular messaging app finally gets
the security it needed. And we've just rolled out E2E to 1b 'monthly active
users'.

However, I have always wondered one thing about WhatsApp: How does it generate
any kind of meaningful revenue? Apparently they've ditched the old $1
subscription model [0], and even that was so loosely enforced that I have
never paid a single cent for WhatsApp in my life--and never will (got it while
it was free on the iOS App Store and now have a 'Lifetime' subscription, if
they don't change those at some point). And even back then, maybe half of
their 900m monthly active users [1] were iOS users who paid only once, and the
rest may have dodged the fee in various ways. I have a really hard time
believing the revenues so gained could ever actually cover the cost of R&D
(especially for so many platforms) and infrastructure (which should be huge,
given the amount of data they shift). Now they say they want customers to use
WhatsApp as a platform, the way Facebook Messenger is doing it, but I'm not
seeing any of those features implemented anywhere. I always assumed there was
some heavy data analysis going on behind the scenes--which would have been
fair, I guess, since we're neither being shown ads nor really paying.
Facebook's involvement added to that conviction. Now that they're encrypting
everything (which, again, is wonderful), they can't analyze what is really,
really interesting data anymore (keywords, etc.). And it's not like there was
a public outcry for them to take this step--I would guess that not many end
users actually appreciate the importance of E2E encryption.

So the question remains: How are they making money? You still have metadata (I
presume), but then again, how do they use this data to make money if they
can't always match it to a Facebook profile (where they can show you ads), and
also, does this data really provide such a big improvement over all the data
collected by Facebook and Facebook messenger? It just seems strange to me that
WhatsApp apparently does not want to make any money.

Does anyone have any insight on this? What am I missing?

[0]: [http://www.cnet.com/news/whatsapp-kills-1-subscription-
fee/](http://www.cnet.com/news/whatsapp-kills-1-subscription-fee/) [1]:
[http://qz.com/495419/whatsapp-has-900-million-monthly-
active...](http://qz.com/495419/whatsapp-has-900-million-monthly-active-users-
but-still-no-business-model/)

~~~
giancarlostoro
I figure this isn't the question others want to discuss, but I too wonder the
same. I think I used WhatsApp for a short period of time, until the point they
asked me for money. Since then I haven't looked back. Now I am left wondering
where their revenue comes from.

~~~
BozeWolf
It probably doesnt need to generate any revenue (in dollars, perhaps when
measured power it does). Facebook does not really want it to be profitable, at
least not as long as the communication is c2c. Facebook is only profitable
because of its b2c parts!

------
ThrustVectoring
That's great news - secure-by-default is a huge thing, since it makes
encrypted communication more normal. If most of your real-time communication
is encrypted, then when and to whom you used encrypted communication isn't
leaking valuable information.

The next step is some kind of noise injection into the metadata. There are
almost certainly ways to look at who is chatting with who when. It'd be
fantastic to automatically generate realistic-looking traffic to hide the
normal stuff within. Plus, you'd be adding deniability to any communication
you're having.

There's likely some pretty severe battery usage issues with it. If you offload
the metadata fuzzing to a proxy server of some sort, then you're adding a
vector to filter out that fuzz. It might be too big of a technical tradeoff to
be worthwhile.

~~~
lazard
We're using noise to hide metadata in the Vuvuzela messaging system [1]. Using
noise to hide metadata is efficient and gives good privacy (better than Tor-
based approaches). We've formalized the privacy guarantee using differential
privacy and are now working to make the system more user-friendly and easier
to deploy.

[1]
[https://github.com/davidlazar/vuvuzela](https://github.com/davidlazar/vuvuzela)

------
samueloph
Great, now I really hope Telegram folks realise how much they already lost for
not having open sourced their servers. Here in Brazil they've lost a huge
amount of community power to Actor, which doesn't even have encryption.

Now, it's a shame Whatsapp doesn't have an open source client as well. As much
as I appreciate encryption, it still looks like we're not going anywhere with
a closed sourced program that is a pain in the arse to run on Linux.

------
free2rhyme214
Telegram secret chats are device specific which means you can't recover them
if you get a new phone. How can Whatsapp recover encrypted chats on iCloud?

------
mtgx
Whatsapp's own post:

[https://blog.whatsapp.com/10000618/End-to-end-
encryption](https://blog.whatsapp.com/10000618/End-to-end-encryption)

I'm grateful Whatsapp itself finally made a public statement about this as
well, but I would hope they would go a step further and integrate this new
change into its Privacy Policy as well.

Then they would be at least _somewhat_ legally committed to using end-to-end
encryption for the foreseeable future in which they'll keep using e2e
encryption. I'd have a little more trust in them that they aren't just going
to drop the E2E encryption for various individuals with just a phone call from
government officials.

------
robert_foss
moxie: Does this mean that both Facebook and Signal servers are unable to see
the plaintext?

(I would assume so, but I would like to have it confirmed. From someone who
actually knows what he's talking about.)

~~~
moxie
Correct. The only people who can read a message (or hear a voice call) are
their intended recipients.

~~~
toupeira
Would it be possible for Facebook to introduce a backdoor later without
breaking the Signal protocol, or alternatively "forking" it while keeping
compatibility between their clients?

~~~
pfg
The client has access messages in clear text. A backdoor could easily deliver
those messages to a third-party, yes.

This is not something E2E protocols can protect you from. You'd have to audit
every piece of firmware and software on your device to verify that's not
happening.

------
antihero
Kind of weird but I got the message claiming my chats were e2e encrypted but
when testing it with a friend, his said no such thing, and his client claimed
mine was out of date and our messages were NOT encrypted, despite there being
a lock my side.

[https://imgur.com/a/pgJsH](https://imgur.com/a/pgJsH)

This is kind of worrying. I'm sure it's not malicious but I have literally no
idea if things are encrypted right now.

~~~
barbs
There was another comment in this thread that said one of you might have stale
data. If you kill the app and try again it should update.

[https://news.ycombinator.com/item?id=11432356](https://news.ycombinator.com/item?id=11432356)

~~~
antihero
We went as far as killing the app, rebooting our phones, etc.

------
talles
> The Signal Protocol library used by WhatsApp is Open Source, available here:
> [https://github.com/whispersystems/libsignal-protocol-
> java/](https://github.com/whispersystems/libsignal-protocol-java/)

[https://www.whatsapp.com/security/WhatsApp-Security-
Whitepap...](https://www.whatsapp.com/security/WhatsApp-Security-
Whitepaper.pdf)

------
xmpir
Does anyone know how the WhatsApp backup to Google Drive is encrypted? If so,
how can it be decrypted so easily from a new phone with the same number.
Clearly either WhatsApp or Google have to store a key - or am I missing
something here?

~~~
odinduty
I'm not sure, but I think WhatsApp stores your key and it sends it to your
mobile so you can decrypt the backup you downloaded from Google. But you can
disable backups...

------
derFunk
Much appreciated! Girls behind me in the train were already freaking out about
the message which popped up in the chats. I guess they don't really understand
the value :)

------
educar
OT but
[https://whispersystems.org/workworkwork/](https://whispersystems.org/workworkwork/)
was great to read. I would definitely apply if I was in the market for a job.

------
amluto
Is it still the case that verifying a user's text identity does not verify
their voice identity and vice versa?

IMO it would be very nice if calling someone and verifying the short code
would confirm their text identity as well and if, once someone's text identity
is verified, if voice calls to that person were protected by the verified text
identity.

(IIRC the reason that Signal does not work this way is that texts use Axolotl
whereas voice uses ZRTP and the key material is completely independent.)

~~~
moxie
WhatsApp uses a shared identity across text and voice, so Signal Protocol is
used to secure both connections.

We've long planned to do the same thing in Signal, but WhatsApp is ahead of
Signal here. Axolotl is now called Signal Protocol, btw.

~~~
simoncion
Speaking of voice calls, are there near-to-medium-term plans to do _multi-
party_ voice calls in Signal, or would such calls be too awkward for various
reasons?

------
squidlogic
Does anyone know if WhatsApp still stores your master key? I assume you can
still reset your password.

If so, kind of makes you wonder what you really buy by adding the axolotl
protocol. Thoughts?

------
zeveb
Very cool, but I wonder when it'll be possible to key Signal off of something
other than my phone number, and when it will be possible to support multiple
accounts (e.g. phone numbers) on a single device. Also, I wonder when it'll be
possible for me to successfully reset Signal registration.

And when I'll be able to share my certifications of contacts with other
contacts …

------
sidcool
How does this compare with Telegram?

~~~
moxie
By default, Telegram stores a plaintext copy of every message you've ever sent
or received on their servers. WhatsApp does end to end encryption using the
Signal Protocol by default, and doesn't store anything server side.

~~~
MrMullen
Don't forget that Telegram uses custom in house encryption and they say "trust
us", it's good. Telegram encryption can't be verified.

~~~
dest
As long as the clients are open-source and the encryption is end to end, can't
it really be verified?

Whatever the server, if the client encryption is reliable, data can't be read
on the server side.

~~~
pfg

      if the client encryption is reliable
    

It's not[1].

[1]:
[https://eprint.iacr.org/2015/1177.pdf](https://eprint.iacr.org/2015/1177.pdf)

~~~
janinge
It is not, or was not? Did this issue get rectified by Telegram?

~~~
CiPHPerCoder
No, they still use MTProto and not an AEAD construction.

~~~
janinge
I was referring to the padding attack. Did they patch this?

And are there any property of MTProto that makes it infeasible to replace AES
IGE in a later revision of the protocol?

~~~
CiPHPerCoder
The problem isn't IGE. It's that they're using SHA1 (not HMAC-SHA1) in a "MAC
and Encrypt" construction.

------
cft
Looks like they feel threatened by Telegram growth, which means Telegram is
doing quite well.

~~~
jszymborski
All they need to do to supplant Telegram (at the very least for my use-case)
is to have a decent desktop app, preferably native. Their current web
interface (is that still active?) is a UX nightmare. Of course it's "for the
sake of encryption" but it comes at the cost of adoption.

~~~
theshrike79
Also Telegram has built-in bot support, which is a big plus in my book.

------
rguldener
I am not seeing the information about encryption they mention in any of my
chat details on the iOS client. Is this part Android only or did simply non of
my contacts upgrade yet? I have version 2.16.1

edit: After a while it now shows up with certain contacts for me

~~~
motdiem
I got a message in my stream right after I sent a message saying 'the messages
in this conversation are now protected by end to end encryption' clicking on
it takes you to this page
[https://www.whatsapp.com/security/?l=en](https://www.whatsapp.com/security/?l=en)
\- I'm using 2.16.1

~~~
subliminalpanda
Still not seeing it myself. I wonder if this is being rolled out in chunks.

------
MichaelGG
Cool! Though am I the only one wondering how this fits into FB's plans? I
suppose they still get all contacts and know how frequently I contact them,
which builds very valuable info. (Something MSN Messenger never leveraged,
sigh.) I'm still very hesitant about ever trusting anything to FB.

Apparently by default there's no notification of changed keys: "WhatsApp users
can opt in to a preference which notifies them every time the security code
for a contact changes". I guess the question is, does this preference get sent
to the server or exposed any other way? If it doesn't then it might be too
risky to use this as an attack channel.

------
dave2000
One thing that's odd about this is that it's phone only, so they need your
phone number. It would be a million times better if it were an android app you
could sideload onto any device and use anonymously; exchanging your contact
details anonymously. It's hard to see how whatsapp can legally/technically
defeat a request for `which contacts does this person communicate with`. The
same goes for the Signal app too. Am I missing something here? Clearly none of
the protocols require phone numbers, so why do the implementations?

------
caf
So exactly how do group chats work in Signal Protocol?

------
teaneedz
How is the WhatsApp contact list data handled? Is it completely encrypted too
or does Facebook have access to it?

~~~
dave2000
Isn't the contact list how whatsapp knows how to encrypt messages and who to
send them too?

~~~
teaneedz
Yes, but Wickr keeps it encrypted - salted

------
noja
How does this effect web.whatsapp.com?

------
kinnth
So does this seriously mean that if verified FBI /NSA or anyone else would
have a tough time reading your messages. I just find it hard to believe if
Facebook owns Whatsapp that they wouldn't create some form of backdoor.

Total security layman speaking here.

------
xlynx
I assume old versions can still connect, and therefore there are legacy
unencrypted modes. Is there any protection against downgrade attacks?

------
dave2000
Would it be possible for WhatsApp to be compelled to provide both parties'
private keys/state representing same, and any other data resorted ml required,
such that messages could be captured and decoded, spoofed etc?

------
mifreewil
What is the incentive for Facebook to add encryption here to WhatsApp? Don't
they want to mine every piece of data about every person that they can? I
can't imagine there is that much customer demand?

~~~
somesay
Facebook Messenger is the thing where everything is minded and you'll get all
the AI bots etc.

WhatsApp instead is their chat app for users how don't like Facebook. WhatsApp
has way more users than Facebook Messengers. And now they have the PR and even
don't have to deal with wiretapping requests anymore.

------
Joof
I'd really like the option to send SMS to non-whatsapp users with a GUI
signaling that this is happening (and an option to disallow this). Balancing
multiple text clients sucks.

------
rem1313
What about system-level notifications? They go via Apple/Google and include
message content. If those are not encrypted, then this sort of defeats the
purpose...

------
smaili
Just out of curiosity, this update isn't just magically available for current
versions. Users need to actually update their apps in order to use the new
protocol, yes?

------
erichocean
Signal's stuff is all GPL'd (AFAIK). Does this mean that WhatsApp's clients
(and whatever else would apply) are also released under the GPL?

~~~
Johnny_Brahms
I doubt it. The protocol is well defined, and a single developer could
probably copy in in a reasonable amount of time. I guess that is what whatsapp
did.

~~~
nly
plus the fact, between them Moxie and Trevor probably own the copyright, and
can just provide them with a copy under different terms

------
oye
Also all URIs sent on whatsapp now open with https!

------
partycoder
Mainstream cryptography is the new snake oil elixir.

Just replace cure-all-diseases secret ingredient from mysterious land with
unbreakable secure algorithm that takes trillions of years to crack.

The algorithm is only secure under specific circumstances. The implementation
might be not secure, the hardware it runs on can be tampered, the advertised
security could only be the best case scenario but some protocols degrade
encryption during handshakes... and you can start simplifying the thing by
several orders of magnitude.

------
_wmd
> As of today, the integration is fully complete. Users running the most
> recent versions of WhatsApp on any platform now get full end to end
> encryption for every message they send and every WhatsApp call they make
> when communicating with each other

Emphasizing "running the most recent versions of WhatsApp", does this mean the
fancy new protocol can still be downgraded to the old one by an older client?
I'd save the fanfare for a few more months yet

~~~
folz
Nope. From the article: "Once a client recognizes a contact as being fully e2e
capable, it will not permit transmitting plaintext to that contact, even if
that contact were to downgrade to a version of the software that is not fully
e2e capable. This prevents the server or a network attacker from being able to
perform a downgrade attack."

------
ams6110
Anyone else reading the headline in Emperor Palpatine's voice?

------
libeclipse
Is it open source? I can't find the source code anywhere.

~~~
moxie
[https://github.com/whispersystems/libsignal-protocol-
java](https://github.com/whispersystems/libsignal-protocol-java)

------
DeepYogurt
Signal is a protcol not an app!? Sweet jesus yes!

------
qznc
What next? Will they open-source the client?

~~~
miopa
Ofcourse not. They can't put a backdoor code in the open source. Some people
would build from source, resulting in the corporation not being able to access
their messages when needed. Not really acceptable for the main shareholders.

------
defiancedigital
According to WhatsApp security whitepaper, strp master key is sent throw
network. Even inside encrypted payload, it breaks pfs...

------
jamesdwilson
absolutely no proof it is e2e encrypted without the source.

~~~
tptacek
I'm sorry, but that's not how computer software works. Anyone who knows what a
basic block is can straightforwardly verify the claims WhatsApp is making.

~~~
jamesdwilson
you don't know how e2e security works, do you? without the source, it is not
verifiable. it could be making a copy and sending it in an encrypted side-
channel for example to their overlords.

~~~
tptacek
Very angry open source advocate, I understand how frustrating it must be that
the current safest mainstream messaging protocol is not open source, but once
again: that's not how computer software works. WhatsApp isn't even obfuscated.
There are tens of thousands of people who read "closed source" software as a
_hobby_.

 _Later_ :

Also? That's not what the term "side channel" means.

~~~
jamesdwilson
do you know even with source, backdoors can be hidden? open source is a must
to even begin to work to verify any claims of security.

~~~
tptacek
Your comment here is incoherent. I agree: source can easily lie. How does that
make it the gold standard for verification? The reverse-engineering of the
actual shipped binary (for instance, the ARM code lifted to LLVM) seems like a
safer analysis target. But, what do I know.

~~~
jamesdwilson
I actually in agreement with what you are saying about viewing the shipped
binary, but source is a must also. ideally it is a reproducible build to
verify the source created the binary.

~~~
tptacek
You keep saying "source is a must" but you have yet to explain why that is the
case.

~~~
jamesdwilson
fair enough!
[https://www.schneier.com/blog/archives/2016/03/possible_gove...](https://www.schneier.com/blog/archives/2016/03/possible_govern.html)

i think this is why source is a must. if a user compiled and installed the app
themselves, and hypothetically had the entire stack above it be similarly
open, then it would prevent the kind of attack mentioned.

do you agree?

if the source is closed anywhere in the stack, or pushed out in a walled
garden as it is currently, then it allows the vulnerability mentioned.

~~~
tptacek
I understand what you're saying. I don't think source is bad thing! Source is
good.

But I think you're a little confused here.

The cryptographic building blocks of the new WhatsApp protocol are available
in source code. You can get source for the Signal Protocol (fka Axolotl). You
can get source for the Noise framework. WhatsApp borrowed these tools from a
very open secure messaging project.

You're unhappy that the source code for the fully assembled messaging product
WhatsApp isn't available. I understand that, too.

But you've overplayed your hand by arguing that not releasing WhatsApp source
is fatal to its security. Even if WhatsApp had done that, the overwhelming
majority of its users (in fact: basically all of them) would be installing
binaries. If WhatsApp is so evil that they've backdoored their product, it is
"supervillain monologuing for an hour while the hero escapes"-grade stupid to
leave that backdoor in their source code. Consider that carefully when you
trust binaries from open source companies, by the way!

In reality, source code does very little to resolve the government backdoor
problem. If you want to ensure that your secure messenger hasn't been
backdoored, reverse engineer and/or instrument the build you're actually
running.

Nobody does this, of course. But while lots of people glance at source code
for crypto applications, I think they're pretty much just kidding themselves.
Having the source code makes them _feel_ safer, but it doesn't actually make
them safer.

~~~
zanny
> Nobody does this, of course.

Every Linux distribution out there compiles everything in their repo by hand.
If you use an AUR package of almost everything on Arch, you are building the
software by hand locally from source. You can pull build scripts from
launchpad, the Suse OBS, or almost every distros package repository (they all
have automated build systems for everything, and you can do it all yourself).

Oh, and there is a little distro called Gentoo some people use where you
literally build _everything_ from source yourself.

So nobody builds open source software from source, besides the millions of
people who do it all the time. Sure, it is a tiny fraction of total users, but
there is a dramatic difference between "nobody" and "somebody" just like there
is a dramatic difference in confidence between "were using this secure crypto,
trust us, its there! its not just something else masquerading as secure crypto
that we have backdoors all over!" versus "here is the source, go build it
yourself if you don't trust us".

The value is not in everyone building from source themselves, just like my
confidence in my software is not in auditing every line myself. It is in the
general freedom of information on the security, and by offering the
information to test it myself I will have inherently more trust in a project
even if I never take advantage of that source availability myself - even if
nobody ever _does_ find exploits in the disclosed code, there is still trust a
proprietary vendor can never have that I implicitly give free software
projects because it is much more precarious to backdoor transparent software
than a black box, and by just making the box transparent at all you add value.

~~~
tptacek
I'm not interested in the argument about your freedoms and I don't much care
about things that work only for people running Gentoo. That stuff is a game.
When security really counts, it's used by people who don't build their
software.

That's what happened when Snowden started talking to Greenwald. Unfortunately,
because our field is completely incoherent about security, instead of using a
secure messenger, they used Cryptocat. Oh, the source code for Cryptocat was
easy to get at, by the way! Didn't do much to keep those messages safe.

------
schlowmo
I should use this as a strong argument for the rest of my no-please-not-
another-instant-messenger-i-stay-with-whatsapp-contacts:

When whatsapp is implementing the signal protocol, why should one use whatsapp
in the first place?[1]

I hope this good advertisement gives signal another round of traction.

[1] Ok, you've got me. The less techie contacts will swing the feature-bat and
the other already use signal.

~~~
LeoPanthera
"Normal" people will not have their choice of messenger swayed by any argument
that uses the word "protocol".

~~~
schlowmo
Point taken. If I talk to "normal" people, I wouldn't use the word "protocol"
neither (or at least not as conversation starter). Normal-people-rephrased
it's more like

"When whatsapp take the fundamental core from signal..."

~~~
blackoil
can Signal be used to contact people on Whatsapp?

~~~
schlowmo
As far as I know: no. Whatsapp just implemented the (open source) signal
protocol formerly known as Axolotl with the help of Open Whisper Systems. The
rest of the IM "ecosystem" (like push notifications, contact recognition,
server infrastructure etc.) is left untouched.

