It’s important to note here that even if you turn on this option, Apple does not support full end-to-end encryption, there are still multiple factors that they keep under standard data protection which means they still have the encryption keys. They keep this under the guise of deduplication so they can save on storage costs but some examples of this are:
the apps+file formats you have installed
your phone’s make model and serial number
most metadata that defines what an item represents such as date time modification time
all file checksums (this is scary imo)
They explain how everything with their encryption works here
My experience of checksums are in things like serial where they can potentially recover a corrupt bit.
I presume in the case of encryption, a checksum is more of a hash of the raw data? Like a one-way deterministic compute. Easy to get a hash of data, extremely difficult to get data from a hash.
In which case, it’s fine. Passwords are hashed (granted, multiple times), but a cryptographically secure hash is not to be underestimated.
You are correct, my concern with it isn’t retrieving the data however, its the possibility that if the person involved had the means to, they could have a table of check-sums of files of interest. This system could be used to confirm or deny a file of interest is present on the device.
For the everyday person this is a non-issue, but from a privacy POV you should not be able to get any information in regards to what a file is.
Rainbow tables for password cracking works off a similar system, they take a bunch of commonly used passwords, hash them and compare them to leaked databases. If the hash matches an account you have the password. Most password handlers get around this by salting it, and hashing it repeatedly X amount of times, but I doubt that apple would do that for a checksum(and regardless they would know X and how it was made).
Again though I acknowledge that it’s a paranoia level concern, but I still am firm that a true encryption solution should not be able to get any type of info out of it that may help the third party.
It’s important to note here that even if you turn on this option, Apple does not support full end-to-end encryption, there are still multiple factors that they keep under standard data protection which means they still have the encryption keys. They keep this under the guise of deduplication so they can save on storage costs but some examples of this are:
They explain how everything with their encryption works here
My experience of checksums are in things like serial where they can potentially recover a corrupt bit.
I presume in the case of encryption, a checksum is more of a hash of the raw data? Like a one-way deterministic compute. Easy to get a hash of data, extremely difficult to get data from a hash.
In which case, it’s fine. Passwords are hashed (granted, multiple times), but a cryptographically secure hash is not to be underestimated.
You are correct, my concern with it isn’t retrieving the data however, its the possibility that if the person involved had the means to, they could have a table of check-sums of files of interest. This system could be used to confirm or deny a file of interest is present on the device.
For the everyday person this is a non-issue, but from a privacy POV you should not be able to get any information in regards to what a file is.
Rainbow tables for password cracking works off a similar system, they take a bunch of commonly used passwords, hash them and compare them to leaked databases. If the hash matches an account you have the password. Most password handlers get around this by salting it, and hashing it repeatedly X amount of times, but I doubt that apple would do that for a checksum(and regardless they would know X and how it was made).
Again though I acknowledge that it’s a paranoia level concern, but I still am firm that a true encryption solution should not be able to get any type of info out of it that may help the third party.