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.
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.
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.
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
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.
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.
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.
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.
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 :(
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.
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
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.
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 :)
It's pretty confident this calculator is a cat.
https://i.postimg.cc/90WGjk8t/results.png
What's the use case for this?
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."
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?
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.
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?
Check this one too: https://openmined.org/blog/ckks-explained-part-1-simple-enco...
Good primer on FHE here: https://eurocrypt.iacr.org/2021/slides/gentry.pdf
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.
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
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.
Kudos to the KULeuven alumni, but I am curious if the US finances research on homomorphic encryption still /s