Exploring Fully Homomorphic Encryption

FHE has a storied history, and until relatively recently was considered to be an open problem in the field. Proposed as an area warranting further research in 1978 by Ron Rivest (yes, the same cryptographer who is the the “R” in “RSA”), FHE was not a practical reality until 2009 when Craig Gentry proposed the first mathematically sound viable model. (crypto.stanford.edu/craig/craig-thesis.pdf). In 2009 however, this technique, while viable, was infeasible to implement in hardware or software. It wasn’t until June of 2021 that Google released “A General Purpose Transpiler for Fully Homomorphic Encryption”. analyticsindiamag.com/google-launches-general-purpose-transpiler-for-fully-homomorphic-encryption/ The floodgates are open.

A portmanteau of the root word “trans” meaning across and “compiler” (such as a compiled vs an interpreted programming language), a transpiler takes source code and outputs analogous source code in another high-level language. The word transpiler is a natural fit for what Google is doing with their technique – taking C++ code which operates on plaintext data and modifying it such that it is capable of operating on encrypted data instead, leveraging libraries Google describes as being capable of successfully performing FHE (albeit very slowly). These libraries, while serviceable, require a level of expertise with the underlying cryptographic concepts which makes their use unattainable for many. Google is making a bet: that one day sooner than later FHE will become computationally feasible on commodity hardware, and so creating a layer of abstraction for those skilled in C++ but not necessarily cryptography to take advantage of it.

The most commonly proposed use-case for FHE is the ability to offload data for processing to a third-party not authorized to access it. Compliance frameworks such as HIPAA, GDPR and the Australian Privacy Act all put strict requirements on how information about individuals can be treated – but encrypted data is anonymized data, and thus is not in-scope nor does its exposure present risk. We are living in the information age, and an optimist might call attention to the potential to use this technology for great medical advancement. A pessimist might suspect that fully commoditizing FHE will result in more targeted ads and new revenue streams for marketers!

There is another, less obvious use case for FHE. Being able to operate on encrypted data and return processed encrypted data to an end-user opens the door to entirely new application architectures. Imagine the security benefits of an application that didn’t have access to decryption keys at all! A per-user encryption key stored on a hardware device client-side represents the ultimate future-state of this technology. It’s an expensive proposition to secure a data center. For some sectors, we may be looking at a future where user data might be fully anonymized even to the organizations running the service!

If there is one technology to keep an eye on over the next ten years, this is it. FHE promises to flip contemporary architectures on their head. So many practices have evolved over the past 20+ years based on the fundamental reality that data must be decrypted before operating on it – even SSL/TLS itself makes this underlying assumption about our world. Companies like Google are jumping on the bandwagon, investing in making this technology accessible before it is even fully mature. IBM meanwhile has started offering access to special-purpose machines capable of performing FHE in less time than it takes today. (Could we one day see ASICs, dedicated cryptographic chips, or extensions to x86_64 like we did with AES-NI?) The as of yet unthought possibilities are truly staggering.