3 ms·

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 unencrypte

by jchw 3y ago

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.

deleted 3y ago
[deleted]
wayfinder 3y ago
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.
- jchw 3y ago
  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.

by jchw 3y ago

deleted 3y ago

[deleted]

wayfinder 3y ago

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.

jchw 3y ago
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.