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.
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.
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:
The clients final key share is: M_sc = g . H(m) . S_c . S_sNow 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.