I believe the math you outline above refers to this step, located on page 7 of the Technical Summary:
> Next, the client creates a cryptographic safety voucher that has the following properties: If the user image hash matches the entry in the known CSAM hash list, then the NeuralHash of the user image exactly transforms to the blinded hash if it went through the series of transformations done at database setup time. Based on this property, the server will be able to use the cryptographic header (derived from the NeuralHash) and using the server-side secret, can compute the derived encryption key and successfully decrypt the associated payload data.
Is that correct?
If so, then I agree that it is true that in the PSI system the server secret is completely necessary as part of the decryption process in order to decrypt the matching hash in the pointed-to location in the table. That being said, looking only at the information encrypted by the client, I don't think the server secret comes into play, right?
If I'm misunderstanding, and you're confident that an attacker would have to have the server secret to decrypt a photo (even if they already knew that photo's NeuralHash and were able to defeat the internal layer of encryption), then I definitely recommend posting a well-outlined answer to the Cryptography Stack Exchange, as that would be super helpful!
It is my understanding that the vouchers are only encrypted with a key derived from the NeuralHash of the photo. Therefore an attacker would only need to find a matching NeuralHash, to decrypt the voucher.
Apple needs the blinding key, because they encrypt their list of NeuralHashes hashes first, so that others cannot see exactly which CSAM hashes they're testing against. Therefore they first need to decrypt their own database in order to get the corresponding hash value from which to derive the decryption key.
If Apple is to keep their word about guaranteeing the privacy of non-CSAM photos (which this whole discussion is about them not doing a very good job of), then they would only be able to do that with photos stored in iCloud because of this technical specification as to how the identification process works. That being said, other photos across your device are still monitored in a different way. For example Apple will scan photos that you send or receive via iMessage to automatically detect if they're nudes, and if you're underage, they will block them/send a notification to your parents.
> For CSAM matches, the cryptographic header in the voucher combines with the server-side blinding secret (that was used to blind the known CSAM database at setup time) to successfully decrypt the outer layer of encryption.
In the text you referenced, it specifically says that the blinding key would be needed to decrypt vouchers which are CSAM matches. This is because Apple set up their CSAM database in a blinded manner. Therefore to access a hash from the database from which to derive a decryption key, Apple would need the blinding key to first decrypt that hash value.
However, and attacker would be generating their own (presumably unblinded) database, and therefore wouldn't need to access Apple's blinding key.
The question doesn't presume that, as the the secret for blinding the CSAM database would only be helpful if a third party were also looking to see which accounts contained CSAM.
In this case, the question assumes that an attacker would more or less be creating their own database of hashes and derived keys (to search for and decrypt known photos and associate them with user accounts, or to bruteforce unknown photos), and would therefore have no need to worry about acquiring the key used for blinding the CSAM hash database.
- Yes. I wish that weren't the case, but considering that I can't find a single provider so far who respects end user privacy, I would expect for one who does so to charge more.
- No. Ideally, the provider wouldn't keep any logs, so they wouldn't be aware that the same client was making a subsequent request.
- I guess it's completely up to the provider. As this would be the first privacy-respecting provider, they'll probably have to go all-in with privacy, if they wish to gain traction and popularity within the community. So no, I'd personally hope that they wouldn't do that. However if this were an existing provider hoping to start becoming more private, yet they also have current customers for whom these features matter, then I guess workarounds like this are better than not being able to transition to better privacy in general. Or, even better, offer features like this for customers who need it, but allow them to be disabled from account settings for those who don't want it.
- To me, personally, I do not care at all about metrics. If a client is querying DNS, then it's because they're about to connect to one of my services (leaving cyberattacks out of the picture for the moment), at which point if I wanted to (which I don't) I could collect metrics. That being said, I don't think that, for those who want it, collecting generalized metrics at the country level, for example, would be unreasonable. And other metrics, such as DNS routing based on server "health checks" or number of resolution errors, etc. aren't bad either. It's just imperative that when the company collects these generalized metrics, they have a clear and perfect process of purging the metrics of all PII, and only saving the country name from which the request originated, for example.
Yeah, that's what I currently do. However as traffic grows in both volume and origin, and can be hard (and expensive) to keep up. That's why a privacy-respecting provider who already has the infrastructure would be ideal.
That's a good point. It wouldn't be the first time that providers (most notably VPN providers) have lied about their logging policies with devastating consequences for the end user while they get off scott free. Getting something in writing would be ideal, however I'm not sure I'm big enough yet to work out a custom deal like that with a major provider. Thank you for pointing that out, though.
Yeah, currently I run my own DNS server. However, as traffic grows and so does your customer base and server locations, it would be nice to use a dedicated DNS provider, as they'll already have the infrastructure set up to handle a significant capacity of DNS resolutions quickly, as well as servers around the globe to do so efficiently. In addition to the speed, it's usually also less expensive than setting up and maintaining multiple DNS servers of your own around the world.
A pricing scheme that isn't too far off of what you'd find from most other managed DNS providers. Obviously I wouldn't mind paying more for the "privacy" aspect, as long as the price isn't ridiculous. I don't have any, set numbers, however.
You are absolutely right. I work in the field of information security, where this seemingly backwards approach of thinking can quickly crumble optimistic projects! If you're not implementing security through the mindset of someone looking to break that implementation in every, single way possible, you're going to be in for a nasty surprise... and I'm sorry to say that I've seen it happen all too often.
To be fair, I think it's important for people to promote their ideas, projects, accomplishments, etc. However, I think your point intersects with that in two major areas:
1.) After-Thought: It's important to reflect upon what didn't go as expected, what doesn't look right, and what went wrong, and learn from it (very cliche, I know)
2.) Forward-Thinking: I love to see project that layout a roadmap. Not just a roadmap of "here's what we want to do", but a roadmap of "here's what we want to change", and "here's what we want to fix." This adds an important level of transparency to the project, and can really garner user trust and involvement.
I've had my account disabled in the past (I created it while I was underage, with an adult representing me. Once they changed their terms to no longer allow this, they temporarily banned my account). But, once I turned 18, and was eligible again, all I did was send them one email and they immediately restored/recovered the account for me. So yes, I have been able to get my Coinbase account recovered before.
Yes, I completely agree with you! I think being able to read through the actual code of the software you use, in order to fully understand it, what it does, and how it works is a priceless tool. On top of that, most open source tools also provide live examples of implementations, which can be extremely helpful.
However, what do you say to those who will argue that it's actually the other way around? They'll say that private companies have full developments teams paid and dedicated towards maintaining the security of their products... meaning that more work and research gets done, making them more secure, and trustworthy in the end. Or those who say that open sourcing the code makes it easier to find vulnerabilities?
I'm not sure exactly what you mean. If you're looking for a production example, then here's one:
Priveasy.org is an open source group that uses P5.vc (the shorter domain's letters sounded-out sound kind of like "Priveasy") to configure its servers, as well as to provide nice, compact links to its users, when accesses account resources.
If you're looking for examples of all short domain names, then I recommend checking-out this link, as provided by Someone: https://catechgory.com/
That's very true that they're mostly obscure domains, but that doesn't make them any harder to buy. Most domain registrars will show you all or most possible TLDs that are available for your domain.
You are right though, it is something that would be harder for users to remember than a traditional TLD, but then again, it's only four letters... so I don't know. But still, I use mine for configuring servers or whatever other little thing I need (making incredibly short hostnames, email addresses, URLs, etc.), so I figured many others would do the same... but I guess not.
That would be amazing and terrible all at once: the pandemic could be over sooner, but more people will unnecessarily die before that happens. Although I’m curious as to how permanent the antibodies would be, as I’ve seen that they don’t last long, and even when getting the vaccine, it appears that they’ll have to give it to you multiple times, to maintain its efficacy... so even if antibodies help to stop the pandemic, are they the best, longest-lasting solution?
> Next, the client creates a cryptographic safety voucher that has the following properties: If the user image hash matches the entry in the known CSAM hash list, then the NeuralHash of the user image exactly transforms to the blinded hash if it went through the series of transformations done at database setup time. Based on this property, the server will be able to use the cryptographic header (derived from the NeuralHash) and using the server-side secret, can compute the derived encryption key and successfully decrypt the associated payload data.
Is that correct?
If so, then I agree that it is true that in the PSI system the server secret is completely necessary as part of the decryption process in order to decrypt the matching hash in the pointed-to location in the table. That being said, looking only at the information encrypted by the client, I don't think the server secret comes into play, right?
If I'm misunderstanding, and you're confident that an attacker would have to have the server secret to decrypt a photo (even if they already knew that photo's NeuralHash and were able to defeat the internal layer of encryption), then I definitely recommend posting a well-outlined answer to the Cryptography Stack Exchange, as that would be super helpful!