41–50 of 132 posts
Earlier quoted context omitted.
I wouldn't hold my breath on this. Reducing it by x40 AND making sure that hardware is not leaky.
Wait, how would hardware be possibly leaky? The encryption/decryption can leak data, sure, but that's unrelated to FHE. If your hardware can leak info about the plaintext on the side processing the encrypted data, then you could do the same in software anyway, and the FHE scheme itself is clearly broken...
I am still amazed by the amount of people that still mix security and encryption in-use with privacy. And truth is the whole privacy/security industry is doing nothing to change that. Take this for example "Valuable insights through AI (artificial intelligence), big data, and analytics can be extracted from data—even from multiple and different sources—all without exposing the data, secret decryption keys, or, if nee…
> A very powerful concept for remote processing, supply chain security, and overall reducing trust; but completely unrelated to privacy. It is still related to privacy, but the privacy "attacker" is the execution place, allowing for outsourcing of computations and storage without running into data leaks or violations of data protection laws. Maybe you use a different definition of privacy?
> Today, conventional wisdom suggests that an additional performance acceleration of at least another 1 million times would be required to make FHE operate at commercially viable speeds. At the moment, Cornami is the only commercial chip company to announce a forthcoming product that can meet and exceed that performance level. Is there any comparison performance benchmark for these Cornami chips on real world algorit…
If no one answers here, might try on the FHE.org discord, loads of researchers there who probably wrote a paper on exactly that.
I feel FHE combined with slightly cheaper cost might enable things like community run server-less apps that have user state stored and processed by untrusted nodes with persistent state stored and accessible only by the data-owner. E.g. a simple excel-esque web app which only serves the UI while State and calculations are running on this hypothetical system at no cost to the apps creator with me paying only for exclusively my usage. They provide the code but no one but me can extract my data and the results of any computations, and for the privilege I pay the system.
I miss the days of upload and forget software that just relies on client resources and so require little upfront investment from developers, I feel FHE plus distributed computing could enable this.
I am aware "Web3" claims to want this future as a concept but the cost and utter lack of confidentiality (I can observe all data to and from a contract as well as the sender/receivers identity) makes it a super-niche borderline useless VM. For distributed governance sure, it's a public ballot box (the preface to the first distributed systems example, a single account with credits), but for any application/user data absolutely unacceptable.
Earlier quoted context omitted.
> A very powerful concept for remote processing, supply chain security, and overall reducing trust; but completely unrelated to privacy. It is still related to privacy, but the privacy "attacker" is the execution place, allowing for outsourcing of computations and storage without running into data leaks or violations of data protection laws. Maybe you use a different definition of privacy?
You are right. It is related to privacy, but its not the whole story. Thats what I am trying to say. Running FHE will not magically solve the "data leakage" problem of your AI models, and I believe that the people/companies who don't make that distinction are misleading.
Earlier quoted context omitted.
To make it fast I think we'll need custom silicon. I wonder how many stealth startups exist working on FHE chips?
Are the used operations that exotic that special hardware can achieve massive speedups?
And that, differently, for each access (write and read) to each cell in the table.
Not what you would say feasible right now.
Today, if I understand it correctly, that means the encryption can't be broken on a computer with resources < whatever is required to calculate the square root of 16 ;)
It goes on to grossly overstate the extent to which current IT systems are at risk as well as the extent to which FHE would even address actual IT threats. Plus, anytime anyone claims something is “provably secure”, they are leaving out crucial parts of the system, like the interface with humans or key rotation.
And then there’s the part where the author is a VP of business development at a company that makes FHE hardware. Sigh.
Healthcare is stuck in pre 2000 IT technologies because of privacy concerns. I hope that with FHE, Heathcare providers can move to cloud technologies without fear of losing privacy
fhe doesn't solve this at all. if the problem takes little enough power do be run with the, you can run it without cloud compute or fhe easily.