Hacker News Reader

Comment by wayfinder | Hacker News Reader

Note that most E2E encryption services still let the service read your messages. Apple, Facebook, etc. can still read your messages.

This is because encryption needs keys, but when you talk to your friend over these services, under no point did you personally exchange any keys. This means that you’ve decided to let the service generate and keep the keys for you.

It’s like getting a deposit box at the bank but instead of keeping your key, you give your key to the bank to keep.

What would stop the bank from opening your box would be its own ethics policy and the quality and depth of their internal processes. They are not physically prevented from bypassing them however.

It’s still a W with these rudimentary E2E chat implementations because your ISP and government might find it a lot more difficult to read but it’s not quite exactly super strong security.

View on HN

Apple says that iMessage uses asymmetric encryption, the private key of which is stored only on device. You can choose to believe they're lying, I guess, but what they are describing is indeed possible.

https://support.apple.com/guide/security/imessage-security-o...

Until now, Apple hasn't offered any way of actually comparing what keys you are writing to, though. In other words, there was nothing technically stopping Apple (or somebody with the power to compel them) from adding additional recipient keys to your account that your or your contacts would not be aware of.

This is about to change with contact key verification and transparency, though.

Asymmetric encryption doesn’t change anything. Apple is still the one telling your client whose key to encrypt the data for.

A BIG part of successful encryption is key exchange.

A successful SSL/TLS man-in-the-middle attack exchanges false asymmetric keys.

Read the whitepapers, the client side generates the keys and only transmits the public keys to the server. E2EE is truly end to end (as in client to client). Meta has no access to the content of your messages, same has been true for WhatsApp

I never said the keys are sent to any servers.

They keys are still generated and kept using software they wrote.

Second, they also control who they trade the keys between.

This is contrasted to some chat apps (which are painful asf to use) where you have to manually exchange keys, meaning you have to engage with the party you want to talk to and so you can confirm who you are really encrypting messages for. It’s physically impossible to be given the wrong person’s key because you personally had to get them.

> They keys are still generated and kept using software they wrote.

This is a prerequisite for forward secrecy, which is arguably much more relevant.

> It’s physically impossible to be given the wrong person’s key because you personally had to get them.

Does that matter at all if the (in your threat model non-trustworthy) software just exfiltrates all messages?

If you don't trust your encryption software, it's game over (unless it encrypts everything fully deterministically and you regularly audit its outputs).

Well these apps don’t even let you verify the keys even if you wanted to, so you can’t even tell if it’s being man-in-the-middle’d.

Some people said they are finally adding key transparency features to let you do that, but it should have been there since the start. Something a lot of people already use called SSH literally has had that since forever. It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).

If you implement ANY encrypted protocol, key verification is extremely important. If you aren’t verifying keys are possessed only by your recipient, you cannot verify who can read your message.

WhatsApp has always allowed key verification (at least since they've supported encryption), as far as I remember.

> It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).

SSH/TOFU is one model, PKI is another. Both have their respective merits, especially when combining PKI with certificate transparency.

You can compare verification codes on WhatsApp and (starting ~next week) iMessage [1]. And both are in the process of establishing a mechanism similar to Certificate Transparency for x509 certificates [1][2].

[1] https://security.apple.com/blog/imessage-contact-key-verific...

[2] https://engineering.fb.com/2023/04/13/security/whatsapp-key-...

The keys could be generate on the devices and never leave them.

Of course, if the software is not open source, that's hard to police. But abstracting away the key generation from the user doesn't mean that the services can read your messages.

I don't think this is actually true. As far as I understand it, Apple is generating an asymmetric key on client and not sending the private key in an unencrypted form at all. I am a bit fuzzy on the specific details for iCloud but IIRC they basically have your devices verify each-other and then the key exchange process happens between them. Authentication uses SRP challenges instead of traditional password authentication, which means the password itself can be used with a KDF for keychain recovery, since Apple never sees it (not in hashed for, not over TLS, not during signup, etc.)

Even with that, there are still two concerns:

- Compromised clients: either malicious updates or buggy code.

- Security design issues: for example, if iCloud can just surreptitiously add keys to your account, it can trivially make the security moot. (I am aware this is currently an issue, though apparently it is finally going to be resolved somehow.) At least this one is tamper-evident though.

I hope I'm not misrepresenting reality here. Either way, software with reasonably strong E2EE guarantees that still has decent user experience is more possible than it ever has been. The last remaining problem is account recovery, and Apple has a bit of a leg up on this one since a lot of Apple users will have multiple devices that they can use as a backup, even if they lose a device and forget their password simultaneously.

It doesn’t really matter how Apple is doing because the rules of cryptography are set in stone.

- To ensure that you message is unreadable, you must correctly encrypt the data symmetrically or asymmetrically with a key. Well we can assume Apple or Meta can do this properly.

- Second, as the sender or recipient, you MUST verify the authenticity of the key, whether you are using asymmetric or symmetric encryption.

In TLS/SSL, key verification is handled by third parties called certificate authorities.

In SSH, key verification is handled by comparing the key signature that the SSH client displays.

Most of these services right now do not do either (trusted third party or display of a key), therefore it cannot be verified overall. (That said, some people said they are doing what SSH is doing soon.)

I’m happy Apple is doing those things to exchange your own key between your own devices. This is already way better than most services. However, that problem is orthogonal to the problem of key exchange between you and a recipient.

TOFU (Trust on First Use, e.g. what SSH is doing) is already the defacto standard. The only difference is that the warning is less annoying in Signal/iMessage (soon)/etc. Matrix and Signal also offer out-of-band verification, but since compromising TOFU requires actively compromising a user before the key exchange (and it's tamper-evident) it's not really a very big concern for a vast majority of communication.

I know the argument is somewhat moot because they're all closed source. But with WhatsApp and Apple shipping key transparency, this isn't necessarily true anymore. You can verify that the keys that were given to your contacts are the keys that were generated on your device without needing to meet in person.

WhatsApp shipped key transparency before Apple. I assume FB will follow.

Reply on news.ycombinator.com