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