Craig Gentry on board the mothership. ( credit )
A couple of weeks ago I polled readers for the subjects that they were interested in. You gave me some excellent responses, and I promise they’re all in the hopper.
By far the most popular requestwas for some background on the recent results in computing on encrypted data , or ‘Fully-Homomorphic Encryption’. Even though the current techniques are still in the research phase ― way outside the domain of the ‘practical’ crypto I usually talk about ― this topic is so neat that it deserves a few words.
Before I get started, I want to make a few important stipulations. First, I’m hardly the world’s leading expert on the subject. Moreover, plenty of real experts have already published highly accessible introductory pieces. If you’re interested, you should check out Craig Gentry’s fantastic intro paper , or even his (surprisingly readable) PhD thesis . Alternatively, you can go directly to some of the recent papers on FHE.
My last warning is that this subject is kind of involved. I’m going to do my best to keep this explanation relatively non-technical (see the papers above if you want the gory details), but it could still get fairly long .
In this first post I’m going to cover some of the background behind FHE, and explain why it’s such a neat problem.
Why encryption is not like a safe
( credit )
People love to use analogies to talk about encryption. Sometimes these are helpful, sometimes they’re just limiting. Consider this one:
Encrypting a document is like placing it inside of a locked safe.
The locked safe is a great teaching example because cryptography and physical safes (usually) serve the same purpose: they ensure the confidentiality of sensitive data. In practice, they also share many of the same drawbacks.
If you’ve ever worked in an environment where safe-storage is required (e.g., a bank or intelligence agency) you probably know what I’m talking about. Onceyou lock a document into a safe, yourdocument is locked inside of a damn safe .
Consequently, people tend to remove useful documents from safe storage at the first chance they get. This exposes them to all the usual threats, and explains whyso few cases of document theft involve safecracking. Typically the same principle holds for encryption. People decrypt their data so they can use it.
But analogies are never perfect.Encrypting a document isn’t the same as putting it into a physical lockbox. And this is a good thing! Because in fact, there is a kind of encryption that allows us to bypass some of these limitations. We refer to this as homomorphic encryption , and its defining characteristic is this: you can perform useful operations on encrypted values without decrypting them first.
This may seem like an exotic property. Trust me, it’s not. In fact, cryptographers have put a lot of effort into removing the homomorphic properties from common public-key schemes like Elgamal and RSA . Without those protections, both schemes are homomorphic with respect to (modular) multiplication. This means you can multiply together any two Elgamal ciphertexts, and upon decryption you’ll find that the (single) resulting ciphertext now embeds the product of the two original plaintexts. Neat!
Homomorphic encryption has some immediate practical applications. Consider the Paillier scheme that’s used in several electronic voting protocols. Paillier is homomorphic with respect to addition .Now imagine: each voter encrypts their their ballot as a number (0 or 1) and publishes it to the world. Anyone can now tally up the results into a final ciphertext, which makes it hard for a corrupt election judge to throw away legitimate votes . Decrypting thefinal ciphertext reveals only the total.*
A few bits of historyHomomorphic encryption is hardly a new discovery, and cryptographers have long been aware of its promise. Way back in 1978 (about five seconds after the publication of RSA ),Rivest, Adleman and Dertouzos proposed homomorphic encryption schemes that supported interesting functions on encrypted data.Regrettably, those first attempts kind of sucked.** Thus, the agenda for researchers was twofold: (1) come up with secure encryption schemes that could handle useful homomorphisms, and (2) figure out how to do interesting things with them.
To be interesting, a homomorphic encryption scheme should at very least permit the evaluation of useful mathematical functions, e.g., polynomials. But no computer scientist in history has ever been satisfied with mere polynomials.The holy grail was something much neater: a scheme that could handle arbitrary computations ― embodied as real computer programs! ―on securely encrypted inputs.
This idea ― sometimes called ‘ cryptocomputing’ , or ‘ computing on encrypted data ‘ ― has a way of capturing the imagination. There’s something fascinating about a computer that works on data it can’t see.More practically, a technology like this would eliminate a very real weakness in many security systems ― the need to decrypt before processing data. It could even spawn a whole businessbased on outsourcing your computations to outside parties. (Something you obviously wouldn’t do without strong cryptographic protections.)
Anyway, it was a beautiful dream. There was just one problem: it didn’t work.
To explain why, let’s go back to some of the encryption schemes I mentioned above. Throughout the ’80s and ’90s researchers came up with these, and many more interesting schemes. Quite a fewsupported some kind of homomorphism, usually multiplication or addition.However, none seemed capable of handling even both operationssimultaneously ― at least not without serious limitations.
For researchers this was frustrating. Coming up with such a ‘doubly homomorphic’ scheme was an obvious first step towards the higher purpose.Even better, they quickly realized, this ‘first step’ was also the last step they’d need to achieve arbitrary computation.
How’s that? Well, imagine that you have a doubly homomorphic encryption scheme that en