
There is a WhatsApp 'backdoor' - t0b
https://tobi.rocks/2017/01/there-is-a-whatsapp-backdoor/
======
WireWrap
> Signal does not have this vulnerability, but WhatsApp has it.

That might need a footnote or something. TheGuardian is reporting: Moxie
Marlinspike of OWS said Signal planned to make blocking notifications an
option for some users and use non-blocking notifications by default.

[https://www.theguardian.com/technology/2017/jan/14/whatsapp-...](https://www.theguardian.com/technology/2017/jan/14/whatsapp-
vulnerability-secure-messaging-apps)

~~~
ycmbntrthrwaway
With this option it is still possible to use the app securely. WhatsApp is
insecure for everyone.

------
ycmbntrthrwaway
Still not sure if the vulnerability is intended, but the idea of sending
garbage is great. The vulnerability is definitely fixable even if you want to
have security disabled by default.

Edit: after some thought, it is not that easy. If you resend garbage of the
same size and then after some time you click "resend" and send batch of
messages of the same size, then you likely have confirmation enabled.

So users who have confirmations disabled should send garbage too, when they
open the application after some messages were resent.

Again, the idea is great, but needs more thought to make a working solution.
Cover traffic is not simple.

~~~
FabHK
Good point. You could:

If notifications/blocking disabled (newbie setting):

Send re-keyed ciphertext immediately.

Random time later send garbage (automatically discarded by client)

If blocking enabled:

Send re-keyed garbage immediately.

When consumer notices the popup some (random) time later,

\- and clicks "re-send": send re-keyed ciphertext

\- and clicks "discard": send re-keyed different garbage.

However, note that if a compromised server MITM, they will probably be able to
tell the difference between garbage and actual message (because the server
provides the bad key, so can decrypt the immediate response message). It's
really not trivial. Don't roll your own crypto... :-)

~~~
ycmbntrthrwaway
> Random time later send garbage

Random is bad because you need some random distribution and by gathering
statistics server can determine if your distribution of delays match. Delay
until really clicking the button would be highly individual. That is why I
said "when they open the application".

~~~
FabHK
True, if you did this, you'd want to either match the (empirical)
distribution, or, as I believe you are suggesting, just pretend the (non-
existing) button was pressed shortly after the user opens the app next time.

