.png)
3 months ago
5
Fully homomorphic encryption (FHE) is a cryptographic technique which allows computation over encrypted data. This almost magical ability to allow third parties to process information without being able to see it has the potential to greatly enhance privacy and security of applications on the Internet. For the past year, my colleagues and I have been building an encrypted genomics app called Monadic DNA. As the app approaches beta, here are the main lessons we have learned about the state of FHE along the way.
Although FHE has been around since 2009, it has not gained widespread adoption so far due to a reputation for being ponderously slow and complicated to handle. In fact, a financial company I previously worked for did some FHE-related pilots around a decade ago and quickly discarded them. What people don’t realize however is that the blockchain industry has spent hundreds of millions on applied cryptography such as FHE, MPC and ZK amidst its other extracurricular adventures. As a direct result, there are now scalable platforms that make frontier cryptography vastly more performant and user-friendly. Tfhe-rs, the FHE library we are currently using keeps improving on its benchmarks while allowing us to code relatively frictionlessly in Rust. Relatedly, major companies such as Google and Apple are also building with FHE in earnest now.
Key management is always a challenge with any cryptography-focused app. This becomes doubly hard with data sovereignty where users must own and manage their own keys. By many accounts, the web3 approach of using browser plug-ins and hardware wallets has been a UX failure, especially on the onboarding front. Happily, building on mobile solves this as most mobile devices these days come with secure enclaves such as the iOS Keychain. FHE keys for users can simply be generated transparently in the background and then stored and used securely in secure enclaves. If users are prompted successfully to turn on features such as iCloud syncing for their iOS Keychains, they get secure, multi-device sovereign key stores with low usability overhead, leading to a superior user experience.
When I first started prototyping the core FHE-based algorithms we needed for our app, I was pleasantly surprised by the performance I saw. On an M1 Mac Mini, I was able to encrypt half a million rows of data in about two minutes using half a gig of memory and an algorithm iterating over the entire dataset also took about two minutes. The CPU-based back end for our alpha app similarly returns results for users consistently in under two minutes under reasonable load. With GPU acceleration, we expect the performance to improve further, to the extent that the app doesn’t subjectively feel any slower than a regular app. Unless latency really matters, e.g. a trading platform, computation over encrypted data is now sufficiently performant for most apps.
FHE in action on a low bandwidth connection.
The big caveat with using FHE for security and privacy is that encrypted data sizes are absolutely enormous. A single 5 MB raw genomic dataset blows up to around 300 MB once it is encrypted and serialized for storage on the server, even after using compressed integers, etc. Serialized server keys themselves need around 30 MB each for storage on the back end. This inflates storage costs even in this age of low cost storage and adds an important consideration for those looking seriously at FHE. One must also consider that this data needs to be loaded into memory for each evaluation, requiring either a high capacity infrastructure or reduced computational throughput. On the infrastructure front, declining storage costs are more promising than any progress with the cryptographic libraries themselves.
Encrypted storage and compute of any kind will always incur a usability penalty over its plaintext counterpart. There will always be friction, no matter how thought out the interaction or common its use. The key question for each app then is whether the usability friction from FHE use is within users’ tolerance. Between frictionless key storage and decent compute times on the server side, we are pretty optimistic about the usability and accessibility of our app. Our domain, like most others, doesn’t rely on sub-second response times so the overhead of accommodating frontier encryption is definitely worthwhile. We do suffer from some onboarding friction due to the sheer size of the encrypted genomic data that needs to be uploaded to the server but this is certainly not the case for many consumer apps. Even for our app, the one-time cost is defrayed by the utility over months and years as there is no ongoing usability challenge for our users.
FPGA-based hardware acceleration is at the current frontier for accelerating FHE computation. Key bits of FHE functionality are delegated to hardware so that the overall speed of computation is improved significantly. Having seen FPGA acceleration pay dividends for intensive derivative finance computations in my own career, I tried Belfort Lab’s solution for FHE on our genomics algorithms. As I noted on X, we saw greater than ten-fold speedup across the board on our code. Indeed, at the FHE Hardware Acceleration Summit last month, several companies talked about using FPGA acceleration with their applications. While the costs of these cutting edge solutions are still not clear, we hope to soon run a proof of concept to establish whether hardware acceleration will allow us to deliver results to users closer to real-time, thus solving the last piece of the usability challenge.
Just as switching from imperative to functional programming or vice versa needs a frame shift, so does writing code for FHE. Particularly because equality is tricky to handle under encryption, many bits of logic have to be expressed differently and this adds overhead beyond just operating on massive ciphertext. Lookups in tabular data go from a constant-time to a linear scan through the entire dataset. A frequency count of entries in a table goes from O(n) to O(n*m) and so on. At first trot, this is awkward and difficult and testing code locally is a pain. After a while, coding in this alien way starts to make more sense and prototyping no longer feels painful. For this reason alone, only the most minimal and sensitive bits of computation should be done under FHE as far as it can be helped. This is similar to how for smart contract applications only the most minimal computations should be on a blockchain.
There are already multiple schemes (e.g. TFHE, CKKS, BGV) for FHE leading to a variance in library implementations. To complicate matters further, well-funded and fast moving companies also have their own library implementations without any explicit cross-compatibility. We have so far gone with Zama’s tfhe-rs as it is reasonably mature and is now committed to backwards compatibility between library versions. Companies such as Sunscreen are doing promising work and it’s always good to have multiple options in such a security-sensitive domain. However, it is currently really difficult to switch between FHE libraries or to combine them since there is no concept of deterministic key generation from fixed seeds or any ciphertext compatibility. We are assuming this kind of lock-in will not be commercially viable in an emerging market and some industry standards will eventually be set.
While we have satisfied ourselves that FHE works pretty well for a consumer app providing data sovereignty to individual users, we have not found a satisfactory pure FHE solution for analyzing data from multiple users. This is pretty important to have since it will let us facilitate research studies and other types of analysis with user consent. Not only would pure FHE require either a trusted and exploitable intermediary or a very complex key exchange system but it would also require analyses over huge amounts of ciphertext. Even if the cryptography were to become practicable, the sheer storage and computation costs would be prohibitive. Realistically, we need to combine FHE with MPC (multi party computation) and TEEs (trusted execution environments) to get a workable protocol going. We suspect this will be true for all other consumer apps using FHE.
(I described our work with Nillion MPC on real users in a recent blog post).
In spite of the performance gains with FHE libraries and increased commercialization, there are no prominent FHE consumer apps yet (although we hope ours will be among the first!). Based on the talks I saw at a recent FHE conference and the listings on fhe.org, the FHE community still seems focused on enterprise use cases. I’ve seen many emerging technologies in the past stuck in corporate proof of concept hell, only to gain eventual traction in the consumer sphere. I believe thousands of everyday apps (e.g. messaging, health, productivity) can benefit from at least light touch FHE, increasing security and privacy for everyone. For this to happen, we’ll need better mobile SDKs and a better developer experience overall. FHE may be a lot more impactful in regular apps than in corporate deployments or confidential blockchain platforms. With just the right amount of standardization, interoperability and smooth hardware acceleration, I can see frontier encryption techniques like FHE changing the Internet for the better.
