Hacker News Reader

Comment by ycmbntrthrwaway | Hacker News Reader

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.

View on HN

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... :-)

Good idea of extending the technique.

I want to address you last concern. moxie's specific concern is that without the extra measure I explained in the blog article, WhatsApp could find out on a large scale, covertly (!!!), who has this setting enabled or not. Simply because after a while pretty much every client will have to face the decision whether or not to retransmit for a benign reason.

Of course if they MITM, they can distinguish the re-send text from the garbage text, but the point is that then they are MITMing already and risk being detected. So instead they could've just MITM the conversation from the beginning on with risking of being detected.

> 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".

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.

Reply on news.ycombinator.com