4 ms·

Agree, also think it's likely this is an intentional trade off: Alice sends Bob a message but Bob's phone is broken, so he gets a new one. The message is marked

Agree, also think it's likely this is an intentional trade off: Alice sends Bob a message but Bob's phone is broken, so he gets a new one. The message is marked as not delivered. Since Bob's old keys are lost, WhatsApp needs to generate new ones. The trade off here allows in this scenario to accept new keys transparently. Not ideal from a security perspective but what would be the alternative? Bob meeting Alice so they can compare fingerprints? Bob sending Alice a PGP signed message?

akjainaj 10y ago
I completely agree with you, and I am going to add that this scenario shows how difficult it is to make a one-to-one messaging system completely secure AND easy to use at the same time.
thinkloop 10y ago
What if the originating client (Alice) was responsible for re-encrypting undelivered messages?
FabHK 10y ago
Could do it like Signal - always alert the user when a key changes, and not resend messages until the user approves it (having checked the key fingerprint via some other channel, if so inclined). As it stands now, you have to trust both the client app on your phone, and the WhatsApp server. The idea with e2e encryption was that you only have to trust the client app on your phone.
MagnumOpus 10y ago
>what would be the alternative Alice getting a warning about key mismatch and a prompt for redelivery (or not) of the pending message. Bob-with-new-phone does not get to read Alice's messages to Bob without Alice at least having the ability to verify that Bob indeed changed phones. Yes, 99% of users will click "redeliver" without checking, but the ones for whom secrecy matters won't. I think this is how Signal does it, and it is the only security conscious way to do it.
- dserodio 10y ago
  Yeah, I've seen this behaviour with Signal. It's UI is somewhat confusing thou, it took me a while to understand that I needed to re-generate keys so what I could "fix" my conversation. There was no redelivery of the messages that couldn't be decrypted thou.
- discordianfish 10y ago
  Yes, I personally prefer that too. But I understand if facebook decided this is too much to ask for their users.

akjainaj 10y ago

I completely agree with you, and I am going to add that this scenario shows how difficult it is to make a one-to-one messaging system completely secure AND easy to use at the same time.

thinkloop 10y ago

What if the originating client (Alice) was responsible for re-encrypting undelivered messages?

FabHK 10y ago

Could do it like Signal - always alert the user when a key changes, and not resend messages until the user approves it (having checked the key fingerprint via some other channel, if so inclined). As it stands now, you have to trust both the client app on your phone, and the WhatsApp server. The idea with e2e encryption was that you only have to trust the client app on your phone.

MagnumOpus 10y ago

>what would be the alternative Alice getting a warning about key mismatch and a prompt for redelivery (or not) of the pending message. Bob-with-new-phone does not get to read Alice's messages to Bob without Alice at least having the ability to verify that Bob indeed changed phones. Yes, 99% of users will click "redeliver" without checking, but the ones for whom secrecy matters won't. I think this is how Signal does it, and it is the only security conscious way to do it.

dserodio 10y ago
Yeah, I've seen this behaviour with Signal. It's UI is somewhat confusing thou, it took me a while to understand that I needed to re-generate keys so what I could "fix" my conversation. There was no redelivery of the messages that couldn't be decrypted thou.
discordianfish 10y ago
Yes, I personally prefer that too. But I understand if facebook decided this is too much to ask for their users.