[agd]

The question for me is that posed by the hacker who discovered the vulnerability. Here's what he said [1]:

"He (Moxie) said: “The choice to make these notifications ‘blocking’ would in some ways make things worse. That would leak information to the server about who has enabled safety number change notifications and who hasn’t, effectively telling the server who it could man-in-the-middle transparently and who it couldn’t; something that WhatsApp considered very carefully.”

This claim is false. Those “blocking” clients could instead retransmit a message of the same length that just contains garbage and this message would just not be displayed by the receiver’s phone. Encryption guarantees the garbage or real messages are indistinguishable in the encrypted form. Hence, this technique would make identifying users with the additional security enabled on a large scale impossible."

This was raised in the previous WhatsApp vuln thread but as far as I'm aware, Moxie is yet to address this criticism. Would be good to get a response on this.

[1] https://www.theguardian.com/technology/2017/jan/16/whatsapp-...

[pfg]

The blocking would occur when the server changes the identity key of a user. If the server does that with the goal of finding out if the user has enabled safety number change notifications, it could just change the identity key to one under the server's control and see whether it receives any garbage.

[kemayo]

I think you're using a different meaning of "blocking" than Moxie is. I believe they mean "blocking" in the sense of waiting for the user to confirm that the message should be re-sent -- i.e. blocking on the user's input. Whereas you're using "blocking" to mean refusing to re-encrypt the message.

Presumably any message which would be detectable enough as garbage to not be displayed on the reader's phone could be treated as them having this feature enabled, allowing the information-leak Moxie mentioned.

(To be clear, I do think there's a argument to be had over which of these leaks is worse. I just don't think this suggested approach actually addresses Moxie's concern.)

[grogers]

Resending and reencrypting the message mean the same thing here, I don't understand the distinction. Once the user okays the key change it can be resent by encrypting with the new key, before that it would be blocked from being resent.

I know nothing of the signal protocol, but whether the server can tell the message is garbage depends on what the receiver client tells the server. An ideal client would acknowledge receipt to the server but show the user an error (or silently drop the garbage message). From the quote it seems like this is the case, in which case the server can't tell a true message receipt from receipt of garbage and the correlation doesn't work.

[pfg]

> I know nothing of the signal protocol, but whether the server can tell the message is garbage depends on what the receiver client tells the server.

You're forgetting that the server is the one telling the sender what the new key is. If the key is under the control of the attacker/server, they can read the message and determine if it's garbage or not.