They have a bit more info on their announcement blog post[0]
> Belfort today released the "so far" CIFAR demo, an encrypted implementation of ResNet-20, a popular model for image classification. It outperforms recent SOTA by 3x with a total latency of less than 200ms
Not many details on how they've done this, so I'm a bit skeptical. Fast HE is a holy grail.
> Belfort's image classification is built on top of its upcoming GPU library, Cyclops. It comes with several optimizations that make Cyclops extremely fast on Encrypted AI workloads.
Looks like a lead up to an upcoming library release
Looked at the network logs and the JS, did some testing, there's a caveat here. For an encryption demo you might expect your secrets to be generated locally, they do the compute on something they can't read, you compare their results to your original plaintext; (imo at least) the point would be that it isn't physically possible for them to cheat.
Here, you literally download client_secret.bin from their server, so they have control over the keys and evaluators. So two things. First, the per user key flow would be several minutes for per user keys, the evaluator bundle would be in the 100s MB to GB realm. Second, there's no way for us to tell the difference between them really doing FHE or decrypting with the key. To be clear, not evidence it's fake, just not total proof it's real. Really hope it's real, been a field I've been following for awhile.
IMO a big unanswered question in FHE (which is my field so I care about the answer) is key management. If you have a service with lots of different users, and each user requires 100 MiB or more in evaluation key material, simply loading that key material from disk onto the GPU for each user's request adds a nontrivial overhead on the order of magnitude of the FHE computation itself. Not to mention the storage cost (for a 1B-user service, each requiring 1 GiB of evaluation key material, requires 1 EiB of storage, which is a hard sell).
So it seems kind of reasonable to me that if you want to showcase your fast inference for its own sake, you can sidestep the remaining engineering problems around key management by giving the user pre-computed key material corresponding to hot-loaded evaluation keys.
Key management is a critical part of the story, as j2kun has pointed out before. In this demo, we're intentionally caching the same key material for every visitor so we can showcase the actual FHE computation without making everyone wait through client-side key generation and upload. Even as a one-time cost, having each user generate their own keys in the browser and transfer them to the server introduces noticeable setup time, which we felt would get in the way of the experience for a demo. We actually implemented it that way at first; setup wasn't a matter of minutes, but we changed course after worrying about the experience for visitors on mobile data.
This demo is focused on demonstrating the computation itself, not a production-grade key management flow. Supporting per-user keys and a more realistic trust model is definitely on our roadmap for future demos.
This is specific to the current state of the demo. Additional techniques can reduce fresh encryptions to only a few times the plaintext size, but they have not been deployed yet.
It uses randomized symmetric encryption with fresh public randomness for every encryption. Ciphertexts are computationally indistinguishable from random and do not reveal whether two encryptions correspond to the same plaintext, different plaintexts, the same key, or different keys.
Nothing is removed. I am not good with dog breeds, but with "German Shepherd", they probably meant the image #27; the black dog. It is indeed classified as a cat :(
Consider encrypted AI. You ask a question under encryption. The remote calculates the answer, which is still under encryption. This is the critical point; the remote cannot see the question and answer. It only calculates. Once you receive the answer, you decrypt it and see the answer; only you see the answer.
Thanks a lot. Though encrypted AI chat bot is not far ahead, do not think of that as the primary target of today. Instead, there are many untapped applications (e.g. inter-bank transfers, industry, healthcare) where regulations, privacy laws and compliance requirements restrict institutions from touching data. These will initially be our key enablers, and over time we hope to extend the range of applications.
Have you considered that maybe the computation itself on the private data, no matter how you put it, even if encrypted, was designed to protect the consumer?
I.E., gaining any sort of insight a transaction of protected information is what the protections were in place for.
So is FHE more about skirting regulations and privacy laws? Or, is it a new frontier of an untapped data source that has some red tape around it?
To me, something was simply not encrypted properly if you are able to draw conclusions/learn insights/detect anything about the data. It's in conflict with the idea of what secure encryption means to me.
The server providing the FHE-based service does not gain any sort of insight. This is a key point: only the client can see the output of the computation.
this is only true in the IND-CPA model for most "practical" FHE work. So a more precise way to describe things is "a server who faithfully performs the task given to them does not gain any sort of insight" (perhaps with an additional caveat about decryption failures).
In the case of single key FHE with server-side processing (the demo setup), the server can never gains any insight, even as an active adversary that can arbitrarily deviate from the protocol because it only has access to public evaluation keys and ciphertexts. The worst it can do is return tempered output to the client, but it doesn't help it learning anything about the client request.
It'll be very useful for even local setups when the data needs to be confidential. Look at the research related to medical training of llms (ignore their current lack of direct usefulness/trustworthiness, those are potentially solvable), with a homomorphically encrypted session, the large inference servers never see hipaa protected data in a way that exposes it if the server is compromised even if its an on premises setup in your doctors office processing the data, reducing risk of the data leaking anywhere.
A local model works when one party owns everything. But often you'll have more than one party, for example different machine operators, the machine manufacturer, the sensor provider, all involved, each with data they cannot or IP they do not want share. That’s where FHE becomes truly useful and more than an additional layer of protection by enabling collaborations that were simply not possible before.
That 90% only measures images already known to be one of CIFAR-10’s ten classes. There is no “none of the above,” so even a perfect benchmark score would still force a calculator into one of those labels.
They have a bit more info on their announcement blog post[0]
> Belfort today released the "so far" CIFAR demo, an encrypted implementation of ResNet-20, a popular model for image classification. It outperforms recent SOTA by 3x with a total latency of less than 200ms
Not many details on how they've done this, so I'm a bit skeptical. Fast HE is a holy grail.
> Belfort's image classification is built on top of its upcoming GPU library, Cyclops. It comes with several optimizations that make Cyclops extremely fast on Encrypted AI workloads.
Looks like a lead up to an upcoming library release
[0] https://belfortlabs.com/blog/sofar
Indeed, we have our own library, Cyclops. We will share more about it soon :)
Looked at the network logs and the JS, did some testing, there's a caveat here. For an encryption demo you might expect your secrets to be generated locally, they do the compute on something they can't read, you compare their results to your original plaintext; (imo at least) the point would be that it isn't physically possible for them to cheat.
Here, you literally download client_secret.bin from their server, so they have control over the keys and evaluators. So two things. First, the per user key flow would be several minutes for per user keys, the evaluator bundle would be in the 100s MB to GB realm. Second, there's no way for us to tell the difference between them really doing FHE or decrypting with the key. To be clear, not evidence it's fake, just not total proof it's real. Really hope it's real, been a field I've been following for awhile.
IMO a big unanswered question in FHE (which is my field so I care about the answer) is key management. If you have a service with lots of different users, and each user requires 100 MiB or more in evaluation key material, simply loading that key material from disk onto the GPU for each user's request adds a nontrivial overhead on the order of magnitude of the FHE computation itself. Not to mention the storage cost (for a 1B-user service, each requiring 1 GiB of evaluation key material, requires 1 EiB of storage, which is a hard sell).
So it seems kind of reasonable to me that if you want to showcase your fast inference for its own sake, you can sidestep the remaining engineering problems around key management by giving the user pre-computed key material corresponding to hot-loaded evaluation keys.
Thanks for taking the time and test it.
Key management is a critical part of the story, as j2kun has pointed out before. In this demo, we're intentionally caching the same key material for every visitor so we can showcase the actual FHE computation without making everyone wait through client-side key generation and upload. Even as a one-time cost, having each user generate their own keys in the browser and transfer them to the server introduces noticeable setup time, which we felt would get in the way of the experience for a demo. We actually implemented it that way at first; setup wasn't a matter of minutes, but we changed course after worrying about the experience for visitors on mobile data.
This demo is focused on demonstrating the computation itself, not a production-grade key management flow. Supporting per-user keys and a more realistic trust model is definitely on our roadmap for future demos.
You could add a toggle, so that if someone's happy to wait for the key setup, they can try the full end-to-end process
Good suggestion. Thanks a lot. Definitely will keep in mind for the next demo
I'm familiar with the team - for what it's worth, its a bunch of legit scientists out of KU Leuven (Belgium) not some vaporware crypto scam lol
Big if true! One of the caveats here is that the file size seems to balloon 341 times.
That's a exceptional tradeoff. Even 3000x is noteworthy as long as processing time does not go to the moon wrt HE/FHE
This is specific to the current state of the demo. Additional techniques can reduce fresh encryptions to only a few times the plaintext size, but they have not been deployed yet.
> Image classification without the server seeing the image.
Does a given plain image always result in the same encrypted payload?
It uses randomized symmetric encryption with fresh public randomness for every encryption. Ciphertexts are computationally indistinguishable from random and do not reveal whether two encryptions correspond to the same plaintext, different plaintexts, the same key, or different keys.
Super interesting work - should become default for sensitive data over time (finance / legal / ...)
I think they only trained on dogs with floppy ears, because it is very confident the German Shepherd is a cat.
did they remove a German Shepherd from the sample images since your comment? I cannot see a German Shepard. Only a black dog with floppy ears.
Nothing is removed. I am not good with dog breeds, but with "German Shepherd", they probably meant the image #27; the black dog. It is indeed classified as a cat :(
keep up the good work. A LLM with holomophic processing would be a killer feature for any corporation which cares about their IP and trade secrets.
I uploaded my own image, tried various crops, but it always guessed cat or deer, with dog<3%.
It's pretty confident this calculator is a cat.
https://i.postimg.cc/90WGjk8t/results.png
What's the use case for this?
From the webpage:
> Image classification without the server seeing the image.
The value is in being able to get the prediction from the model without ever giving unencrypted data to somebody you don’t trust.
You could have an LLM generate code for you without ever giving the operator your proprietary source code.
Consider encrypted AI. You ask a question under encryption. The remote calculates the answer, which is still under encryption. This is the critical point; the remote cannot see the question and answer. It only calculates. Once you receive the answer, you decrypt it and see the answer; only you see the answer.
Ah, that sounds impossible. Good luck, sir...Also, who wants this if you can just run a local model?
Thanks a lot. Though encrypted AI chat bot is not far ahead, do not think of that as the primary target of today. Instead, there are many untapped applications (e.g. inter-bank transfers, industry, healthcare) where regulations, privacy laws and compliance requirements restrict institutions from touching data. These will initially be our key enablers, and over time we hope to extend the range of applications.
Have you considered that maybe the computation itself on the private data, no matter how you put it, even if encrypted, was designed to protect the consumer?
I.E., gaining any sort of insight a transaction of protected information is what the protections were in place for.
So is FHE more about skirting regulations and privacy laws? Or, is it a new frontier of an untapped data source that has some red tape around it?
To me, something was simply not encrypted properly if you are able to draw conclusions/learn insights/detect anything about the data. It's in conflict with the idea of what secure encryption means to me.
> gaining any sort of insight
The server providing the FHE-based service does not gain any sort of insight. This is a key point: only the client can see the output of the computation.
Interesting. I have some homework to do then. Do we have to close our eyes and look away for it to be true or does it really not gain any insight?
Where can I find out more about how this could be possible?
Good primer on FHE here: https://eurocrypt.iacr.org/2021/slides/gentry.pdf
Check this one too: https://openmined.org/blog/ckks-explained-part-1-simple-enco...
this is only true in the IND-CPA model for most "practical" FHE work. So a more precise way to describe things is "a server who faithfully performs the task given to them does not gain any sort of insight" (perhaps with an additional caveat about decryption failures).
In the case of single key FHE with server-side processing (the demo setup), the server can never gains any insight, even as an active adversary that can arbitrarily deviate from the protocol because it only has access to public evaluation keys and ciphertexts. The worst it can do is return tempered output to the client, but it doesn't help it learning anything about the client request.
It'll be very useful for even local setups when the data needs to be confidential. Look at the research related to medical training of llms (ignore their current lack of direct usefulness/trustworthiness, those are potentially solvable), with a homomorphically encrypted session, the large inference servers never see hipaa protected data in a way that exposes it if the server is compromised even if its an on premises setup in your doctors office processing the data, reducing risk of the data leaking anywhere.
maybe it could be running a much more powerful system than you have access to
I can't tell if your being sarcastic but if you can't prove fhe within ( and I'll be generous) a few 1000 lines of code. Bologna.
A local model works when one party owns everything. But often you'll have more than one party, for example different machine operators, the machine manufacturer, the sensor provider, all involved, each with data they cannot or IP they do not want share. That’s where FHE becomes truly useful and more than an additional layer of protection by enabling collaborations that were simply not possible before.
I think calculator is not part of the labels in cifar-10. Pretty normal as it has ‘only’ 90% accuracy. Things could improve quickly though
That 90% only measures images already known to be one of CIFAR-10’s ten classes. There is no “none of the above,” so even a perfect benchmark score would still force a calculator into one of those labels.
yep: https://en.wikipedia.org/wiki/CIFAR-10
"The 10 different classes represent airplanes, cars, birds, cats, deer, dogs, frogs, horses, ships, and trucks."
Kudos to the KULeuven alumni, but I am curious if the US finances research on homomorphic encryption still /s