Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

21–30 of 437 posts

Re: There is no WhatsApp 'backdoor'

#21

tl;dr to me seems: Since users can change devices, they'll need to reissue key material, this needs to be supported. WhatsApp reports key changing optionally, but doesn't tell the server that happened. If WhatsApp tries to backdoor a channel and one of the users has key change notification, they'll find out about it, and WhatsApp has no idea whether the warning was shown.

FTA:

"WhatsApp server has no knowledge of whether users have enabled the change notifications, or whether users have verified safety numbers."

If it's off by default, then the answer is likely to be near zero, as it often is with default options. This isn't an argument about the security of the app (which I have no background to know), more of a comment on relying on non-default behavior.

Re: There is no WhatsApp 'backdoor'

#22
post #5

Color me still-unconvinced. This retort does not address the fundamental point made in the Guardian piece: > “[Some] might say that this vulnerability could only be abused to snoop on ‘single’ targeted messages, not entire conversations. This is not true if you consider that the WhatsApp server can just forward messages without sending the ‘message was received by recipient’ notification (or the double tick), which u…

He does address this: Once the sending client displays a "double check mark," it can no longer be asked to re-send that message.

That means a user is able to verify visually that the end-to-end is working. "users might not notice" doesn't seem to me as a strong argument to state this as a backdoor. This would imply not noticing that you don't have a green padlock on chrome is a backdoor too, and it clearly is not.

Re: There is no WhatsApp 'backdoor'

#23
There seems to be a pretty clear war going on between engineers and journalists lately.

- Chris Latter [1] vs Business Insider [2]

- Elon Musk vs (Bunch of outlets)

- Moxie vs The Guardian

I feel like journalists want to write a compelling story and engineers are on the other side like "No, those aren't facts!" I don't follow a lot of media outlets but it seems like journalists either lack the skills or don't care about doing any technical due diligence.

[1] - https://twitter.com/clattner_llvm/status/819974025371787264

[2] - http://www.businessinsider.com/how-apples-culture-of-secrecy...

Re: There is no WhatsApp 'backdoor'

#24
post #9

>The WhatsApp clients have been carefully designed so that they will not re-encrypt messages that have already been delivered. Once the sending client displays a "double check mark," it can no longer be asked to re-send that message. This prevents anyone who compromises the server from being able to selectively target previously delivered messages for re-encryption. Can this be verified? Can this be verified to be th…

If your threat model includes using a malicious app to send messages then you lose anyway. Nothing can ever be done to send messages securely using whatsapp if the client is neither trusted nor verified. This is true for basically all software that you use.

Re: There is no WhatsApp 'backdoor'

#25

This main flagrant or off-topic, but something that nags at me when thinking about truly secure messaging apps from the App Store: Even with perfect e2e encryption protocol added, what's preventing WhatsApp developers (FB) from adding in a feature of the app: if local.user is "TargetUser007" { takeDeviceSnap(); sendDeviceSnapshotToFBOverSameEncryption(); } Wouldn't this not be ever verifiable unless you ARE that spec…

You'd also have to make sure they were the only user that received that binary.

Otherwise you'd have to hope that no one reverse engineered the binary and noticed the oddly specific comparison there.

Re: There is no WhatsApp 'backdoor'

#27

This main flagrant or off-topic, but something that nags at me when thinking about truly secure messaging apps from the App Store: Even with perfect e2e encryption protocol added, what's preventing WhatsApp developers (FB) from adding in a feature of the app: if local.user is "TargetUser007" { takeDeviceSnap(); sendDeviceSnapshotToFBOverSameEncryption(); } Wouldn't this not be ever verifiable unless you ARE that spec…

I'm sure some security researcher somewhere has run the app through a debugger/disassembler to verify exactly this.

Re: There is no WhatsApp 'backdoor'

#28
post #18

At the end of the day, it comes down to trusting WhatsApp. Even without a backdoor in their protocol, they can easily do all kinds of things. For instance, it could instruct specific clients to encrypt and send each message twice: one for the recipient, and one for the WhatsApp server. As long as this was off for 99.9% of users, it's unlikely that security researchers would ever detect this.

I mean, they're probably disassembling the app, so they'd definitely notice _that_, but there are some truly subtle problems that pop up in security, so your general point about trust seems reasonable enough (certainly for any closed-source remote-updating system).

Re: There is no WhatsApp 'backdoor'

#29
post #7

tl;dr to me seems: Since users can change devices, they'll need to reissue key material, this needs to be supported. WhatsApp reports key changing optionally, but doesn't tell the server that happened. If WhatsApp tries to backdoor a channel and one of the users has key change notification, they'll find out about it, and WhatsApp has no idea whether the warning was shown.

> If WhatsApp tries to backdoor a channel and one of the users has key change notification, they'll find out about it The problem is that the might not find about out retransmissions. You are trusting that the "double-tick" means that the message won't be resent, but presumably WhatsApp can indeed retransmit those messages with the new key under pressure from a state actor. They need to specifically address this poin…

That would require the client to be compromised though right? My understanding is that the client is making the decision whether to retransmit with the new key.

Now it's fair to question whether you can trust the client, but if you can't then there's no limit to what they could do.

Post reply on HN