Hacker News new | ask | show | jobs
by lern_too_spel 2275 days ago
> The fact that it's possible to decrypt is what makes this not "end-to-end encryption".

By that definition, iMessage is also not end-to-end encrypted because Apple can decrypt the messages due to controlling the key servers and the relay servers, but few people bat an eye when Apple claims iMessage is end-to-end encrypted on its privacy marketing page.

https://blog.cryptographyengineering.com/2013/06/26/can-appl...

https://www.apple.com/privacy/features/

3 comments

> By that definition, iMessage is also not end-to-end encrypted because

True, if true (I've not checked the iMessage details), but unimportant.

Whether or not iMessage is end-to-end-encrypted by the actual definition of end-to-end-encryption, does not change the fact the Zoom's communication is not end-to-end-encrypted by the actual definition of end-to-end-encryption while they are persisting in claiming that it actually is.

If they held up a blue ball and said "our ball is bright green", that would be incorrect. If someone else held up a yellow ball and said "our ball is bright green" that would not make Zoom's statement any more correct.

Oh, come on, that’s not the same thing at all. Here Zoom actively decrypts the stream so that it’s compatible with non-Zoom clients and then advertises it as end-to-end, a fault in the protocol itself, while you’re comparing it to (outdated, FYI) information where Apple could possibly decrypt messages if they sent out fake keys.
> Oh, come on, that’s not the same thing at all. Here Zoom actively decrypts the stream so that it’s compatible with non-Zoom clients and then advertises it as end-to-end

I took issue with a specific definition that precludes both products. I didn't say that both products use the same protocol.

> you’re comparing it to (outdated, FYI) information

Has the implementation changed in any way that makes it meet the definition? No? Then the information is not outdated for our purposes.

> I took issue with a specific definition that precludes both products.

This isn’t the first time you’ve tried to compare Zoom and iMessage; it’s just that I chose this one to respond to.

Have I made a false comparison anywhere else, or was the comparison valid as in this case?
You keep drawing parallels between Zoom's end-to-end encryption and iMessage's, when there really is little to compare. iMessage is end-to-end encrypted because intermediaries do not have access to decryption keys; your "attack" relies on a malicious actor tampering with key distribution using a technique that requires even more setup than is described in the old article you've linked. On the other hand, Zoom has been actually decrypting traffic as a key part of their service and yet called it end-to-end.
> You keep drawing parallels between Zoom's end-to-end encryption and iMessage's, when there really is little to compare

Once again, in none of my comparisons have I said they are doing the same thing. Please point to a specific comment I have made that you think is misleading.

It's not outdated; Apple still controls the key distribution and the users cannot verify how many recipient key sets there are.
For one, iMessage (and FaceTime) will now tell you if a new device is added.
No, Apple cannot decrypt iMessage or FaceTime traffic because they don't have the keys.

Apple could silently add an extra recipient for whom they do have the keys, but that is out of scope for E2E (in other words, key distribution is out of scope).

> No, Apple cannot decrypt iMessage or FaceTime traffic because they don't have the keys.

They can very easily decrypt iMessage traffic using the method outlined in the article. They simply provide the sender with an erroneous key.

> key distribution is out of scope

Not according to GGP's definition, which didn't require merely that messages stay encrypted between endpoints but that middlemen have no way of decrypting the data.

Middlemen don't have a way of decrypting the data, because they don't have the keys to decrypt it. If they're malicious they can try to send you new keys to use, and only if you accept them will they then have the keys to decrypt your messages.
> and only if you accept them

Does iMessage give the user any way to reject them? Show me. Apple's own "Apple Platform Security Spring 2020" document does not claim any such thing. It says the device requests keys from IDS at the start of a conversation and just uses them.

The article I linked to above said that Apple fixed several other bugs the researchers pointed out but not that one, which other researchers had also described to Apple years before.