Full Disclosure, I work at IBM on FHE. Readers of slashdot might also be interested to watch this video I linked below in this post. The link jumps right to a demonstration of our FHE AI SDK on youtube, but a few minutes earlier in that video stream there are some use cases explained and some other content. However, I figure news for nerds means show me the code/demo! https://youtu.be/rAW2qVBZdYM?t... The video linked above shows our python FHE programming runtime that is a much more user-friendly programming environment for building FHE applications. This SDK is licensed software. But, if you want to dabble a bit and run a few programs to get your hands on the technology, you can check out our freely available FHE toolkits (that do not have the python magic but are still pretty awesome) here: https://github.com/ibm/fhe-too..., https://github.com/ibm/fhe-too..., https://github.com/ibm/fhe-too... At our github Readmes you can also find out how to join our public slack community to learn more or get in touch.

Full disclosure, I work at IBM on FHE. This is a gross simplification but here goes! The secret data that you want to protect is encrypted by effectively hiding it in a massive polynomial with special modular arithmetic properties based on the private key. Only the person doing the encryption has this key. The FHE foundational operations work on these massive polynomials. So the processor who does the computing only sees huge polynomials. The agent who does the processing of the large polynomials cannot tease out the secret data that is protected (it is simply too spread out throughout these massive numbers represented as polynomials). The magic is that the operations on the polynomials behave in a way that is consistent with having operated on just the secret bits once you a modular arithmetic trick at the end to remove all the "junk" or "noise" that is hiding the real data. Note: There are actually public-type keys involved on the processing side and even some kinds of keys that are only used for internal processes during the computation. But as far as privacy is concerned, only the person who did the encryption (and has the private key) can decrypt the jumble of massive polynomial shenanigans to make sense of it all.

There are literally dozens of viable use cases out there today :) Full disclosure I work at IBM on FHE. A quick survey of any of the companies in the space generally will spell out those use cases at a high level. I am not at liberty to openly discuss my employer's views on which use cases are the most promising, but it is not surprising that most publicly described use cases from a casual search of competitors are aimed at regulated industries with highly sensitive personal information. The applications to finance, healthcare, comarketing, and others are pretty well known among FHE practitioners in well-established firms and startups.

Full disclosure, I work at IBM on FHE! As mentioned in the article we get the speed concerns. It is a major priority for us to make FHE faster and easier to consume. With regards to speed, it is clear that FHE operations are slower than unencrypted operations. Even so, some amazing speed results can be achieved if one stops looking at raw performance numbers compared to unencrypted work. There are many tasks companies would like to do today that they simply cannot because of the risks involved (like computing on your healthcare records or other sensitive personal information). FHE, while slower than unencrypted operations lets you implement FHE systems that can never never be put into production as unencrypted operations. The article mentions an AI inferencing task on genomic data that happens in well under a second. The myth that FHE is too slow to be useful persists. I would argue FHE is ready today for MANY scenarios where latencies in computing are on the order of minutes or seconds (a lot of banking work and healthcare work take longer than those timescales today).

Hey there! Full disclosure, I work on FHE at IBM. I thought you might want to check out the protection of the runtime using something like Hyper Protect to prevent the bad guys from manipulating your data. We open-sourced some code this past week that looks at FHE as part of a comprehensive security model for putting work in public and private clouds. The scripts to deploy the FHE toolkit to Hyper Protect are in the automation directory in our Linux Toolkit Github. We totally get that FHE is not a silver bullet, and we are addressing issues like the malleability concern already with our existing enterprise-grade cloud infrastructure. I think we are further along in providing the hardened comprehensive system infrastructure than any of our competitors.

I am one of the developers so maybe I can help place the illustration in context (it was a single frame from an explainer video). The longer video is available here: https://fhe-website.mybluemix.... The concept is actually simple. Rather than relying on encryption at rest and encryption in transit only (as is the case for modern crypto), you can now leave your data fully encrypted, and have someone else perform computation on that data without giving them access to decrypt it. This is true even at the register and memory level. So with this technology, someone can take even their most sensitive data, encrypt it, send it to the public cloud for analytics or machine learning and never divulge anything about the data nor the results of the encrypted computation. The implications are pretty big and there are many use cases that could really change the way privacy is considered for what has traditionally been extremely private data.