3 ms·

There is so much disinformation about this with people not being informed. Apple have put out clear documentation, it would be a good idea to read it before fea

There is so much disinformation about this with people not being informed. Apple have put out clear documentation, it would be a good idea to read it before fear-mongering. 1) The list of CSAM hashes is that provided by the relevant US government agency, that is it. 2) The project is not targeted to roll out anywhere other than the USA. 3) The hashes are baked into the OS, there is no capability to update them other than on signed and delivered Apple OS updates. 4) Apple has exactly the same leverage with EvilGov as at any other time. They can refuse to do as asked, and risk being ejected from the country. Their stated claim is that this is what will happen. We will see.

benmmurphy 5y ago
Regarding 3: it’s very easy to make a mistake in the protocol that would allow apple to detect hashes outside the CSAM list. Without knowing exactly how their protocol works it’s difficult to know whether it is correct. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni... For example here is a broken PSI protocol in terms of point 3. I don’t think normally in PSI this is considered broken because the server knows the value so it is part of its private set. Server computes M_s = g . H(m) . S_s where g is a generator of an elliptic curve, H(m) is the neural hash of the image and S_s is the server blinding secret. The client computes M_sc = M_s . S_c where S_c is the client ephemeral secret. This M_sc value is the shared key. The client also computes M_c = g . H(m) . S_c and sends the M_c value to the server. The server can now compute M_cs = M_c . S_s = M_sc since they both used the same H(m) values. This allows the server and client to share a key based on the shared image. However, what happens if the client does it’s step using the ‘wrong’ image. If 3) is to hold it should not be possible for the server to compute the key. Client computes: M_sc = M_s . S_c M_c = g. H(m’) . S_c The clients final key share is: M_sc = g . H(m) . S_c . S_s Now server computes: M_cs = M_c . S_s = g . H(m’) . S_c . S_s The secret shares don’t match. But if the server knows H(m’) it can compute: M_cs’ = M_cs . inv(H(m’)) . H(m) and this secret share will match Normally this client side list in PSI is just used to speed up the protocol so the server does not have to do a crypto operation for every element in its set. It is not a pre-commitment from the server. Also, maybe the way I’m doing it here is just normally broken because it is not robust against low entropy inputs to the hash function. I've also reversed some of apple's non-public crypto that is used in some of it's services and they have made dubious design decisions in the past they have created weird weaknesses. Without knowing exactly what they are doing I would not try and infer properties that might not exist or trust their implementation.

benmmurphy 5y ago

Regarding 3: it’s very easy to make a mistake in the protocol that would allow apple to detect hashes outside the CSAM list. Without knowing exactly how their protocol works it’s difficult to know whether it is correct. https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni... For example here is a broken PSI protocol in terms of point 3. I don’t think normally in PSI this is considered broken because the server knows the value so it is part of its private set. Server computes M_s = g . H(m) . S_s where g is a generator of an elliptic curve, H(m) is the neural hash of the image and S_s is the server blinding secret. The client computes M_sc = M_s . S_c where S_c is the client ephemeral secret. This M_sc value is the shared key. The client also computes M_c = g . H(m) . S_c and sends the M_c value to the server. The server can now compute M_cs = M_c . S_s = M_sc since they both used the same H(m) values. This allows the server and client to share a key based on the shared image. However, what happens if the client does it’s step using the ‘wrong’ image. If 3) is to hold it should not be possible for the server to compute the key. Client computes: M_sc = M_s . S_c M_c = g. H(m’) . S_c The clients final key share is: M_sc = g . H(m) . S_c . S_s Now server computes: M_cs = M_c . S_s = g . H(m’) . S_c . S_s The secret shares don’t match. But if the server knows H(m’) it can compute: M_cs’ = M_cs . inv(H(m’)) . H(m) and this secret share will match Normally this client side list in PSI is just used to speed up the protocol so the server does not have to do a crypto operation for every element in its set. It is not a pre-commitment from the server. Also, maybe the way I’m doing it here is just normally broken because it is not robust against low entropy inputs to the hash function. I've also reversed some of apple's non-public crypto that is used in some of it's services and they have made dubious design decisions in the past they have created weird weaknesses. Without knowing exactly what they are doing I would not try and infer properties that might not exist or trust their implementation.