[messaging] Second thoughts on WhatsApp encryption

[Tom Ritter]

On 21 November 2014 08:13, Nadim Kobeissi <nadim at nadim.computer> wrote:
> To me this is kind of a deal-breaker. If WhatsApp's servers and executives
> can decide to revoke my "encryption permit" at any time, silently,
> server-side and without me knowing, what's the point, at all, of having
> Axolotl in the first place? Are we hoping that WhatsApp will play nice even
> when faced with a court order?
>
> I wonder if WhatsApp can remove this server control of who gets encrypted
> chats and who doesn't without having to make sure that all of its clients
> exclusively use Axolotl.

I'm disappointed in this design but no more so than not having OOB key
verification in the initial launch.  And I'm not surprised and I'm
willing to give them a bit of time on it.  It's the simplest thing
that works, and we can't expect a deployment as large as WhatsApp to
have a 'flag day' where all its clients support Axolotl and all users
can start using it right away and there's hard fail errors everywhere.
Phased rollout of features and incremental availability is part of the
game at that scale.


I think that out of band key verification (which is the only thing
that can prevent MITM) should lock a contact into using Axolotl - it's
that simple.[0][1]  I'm absolutely confident there will be a way to
override it, and I'm sure there will be debates about the UI making it
too easy to do (like clicking through SSL warnings) vs making the UI
to confusing, but it should be surfaced to the user.  'This user
migrated to a new device that doesn't support encryption' or 'This
user has migrated to a new device and/or a new key'.

> The issue here is
> that even if key authentication is implemented, WhatsApp servers still
> retain the capacity to selectively disable encryption on a case by case
> basis.

If this is the case after OOB key verification is implemented.... it
would indeed be very bad.  I'm hopeful it will not - we'll have to
wait and see though.



The difference between "WhatsApp can MITM my conversations by giving
me a fake key" vs "WhatsApp can MITM my conversations by saying
'Alice/Everyone doesn't support encryption'" is still important
though.  While they can be seen as technically equivalent[2], I think
legally they are not, because of the points Nathan raised, and because
I think it'd be easier for RepressiveGov or TLA to argue "You have a
switch to disable crypto, use it."

How could this be solved in a world where some clients will not
support Axolotl[3]?  Well, we're trying to solve a problem
anticipating legal arguments or government pressure.  That means we're
speculating wildly.  But let's do it anyway, it's fun!

Probably by moving the logic to the client. Assuming you're not
already speaking Axolotl to Bob, Alice receives a new message from Bob
saying "Hi I'm Bob, [here's my key/I don't support encryption]".  Now
the burden moves from "Just tell them encryption isn't supported" to
"Modify the messages of users communicating with my target while
they're in transit."  But it's still a small kill switch.  How do you
improve that?  Hrm.  The first thing that comes to mind is Bob sends a
signed message "I don't support encryption".  But signed with _what_!
What can we get running on those Nokia 900s!  <_<   >_>   What about
RSA-512? ECC in Binary Groups with a 170bit key? The goal of using
this weak crypto is not to provide security - it can't be achieved
without OOB verification if you assume a malicious server - it's to
make the legal defense better.  And that's wild speculation.

-tom



[0] Technically speaking this is by no means simple because of
multi-device support. First you need to sync all your WhatsApp devices
to authenticate each other's device keys. Then you need to either
support a mode where one of the user's devices supports Axolotl but
another doesn't OR decide that in that case the user doesn't get
crypto.  And when you do out-of-band key verification, you need to
transfer all that information or transfer information that
authenticates that information. (And don't forget allowing Bob to
receive an (authenticated-by-Alice) message saying 'please also
encrypt to my Nexus5'. And don't forget allowing Bob to receive an
(authenticated-by-Alice) message saying 'I just got a Nokia 900,
please stop encryption its tiny heart can't handle it.')

[1] I'm _also_ going to assume that the client honestly does all the
things it claims to do - if we reject that assumption, there's no
point because the crypto could be backdoored, key escrow, whatever.

[2] I wonder if this will make the debate simpler? If you think "It
doesn't matter because they could give fake keys" then you're not
allowed to say whatever crazy shenanigans I come up with are a bad
idea - because WhatsApp could just serve fake keys and my shenanigans
can't account for that.  =P

[3] The more difficult version of this problem is "How can this be
solved in a world where some clients will never be upgraded, and I
have to support the protocol they use currently, forever."