Practical applications of homomorphic encryption algorithms?

Question

It appears there there were interesting things going on in cryptography: the first homomorphic encryption scheme appeared recently (explanation, HT). Roughly sp

Answer 1

I don't know how expensive the f(x) + f(x) computation is going to be, but maybe it could be used as a way of implementing encrypted database.

You can store 1 million rows of some data encrypted as f(x_1), f(x_2), ... f(x_n). You could do

SELECT SUM(x)
FROM Foo
WHERE y = 'some value'

Which could be calculated by first doing SUM(f(x)) then decrypting it to SUM(x).

Answer 2

With this you can execute an arbitrary non-recursive circuit of bounded depth, so given a logarithmic key length you can execute an NC1 algorithm (basically a feed-forward Boolean circuit).

So, how can you use this?

Lets look at Map/Reducing a circuit and reduction scheme over a set of inputs.

First the data:

We probably don't want the client to have to have encrypted all of the data we are going to search, so you can provide an encrypted 1 and an encrypted 0 to the server, and let it use the ring structure to construct arbitrary encrypted integers for us, or we can just use those directly as bits. That way the server can provide some or all of the data that we are searching through. For integers it can construct them by peasant arithmetic (double or double and add 1 for each bit), for bits it just provides the appropriate encrypted bit.

We can mix and match boolean and integer values in our designs, obtaining an if/then/else (that requires evaluating both branches SIMD style) by evaluating cond * then + (1 - cond) * else using 1 as true and 0 as false in cond, so you can get away with using the built in arithmetic of your ring to make your circuits more shallow.

On the other hand, we may have pre-encrypted some data as well, but since you'll have to keep recycling the same key set to use it, this becomes seriously tricky to get right.

So, now we have server provided data. Now, encrypt the stuff you don't want the server to know, like what it is you are searching for, and have them feed that into the circuit at the right points as well, say as an extra input to your map function.

We should be able to map an arbitrary NC1-like circuit over each input to extract a field, multiply some values, and generally map it into a form that you can reduce cheaply.

Then reduce those fragments using more small circuits, such as for a simple monoid that has a nicely size-bounded result. (i.e. you map to obtain a bit that indicates if you found a match, and then you reduce by counting those bits with a small adder circuit)

Since you only need to construct the circuit logically and simulate its execution on these encrypted bits in the homomorphic ring, you could probably implement it relatively quickly using a small DSL, i.e. something like Lava in Haskell, assuming you got the homomorphic encryption pieces straight.

Also, keep in mind that each gate is seriously expensive to execute.

So, to summarize,

1. Give the server an encrypted 1 and 0 and any encrypted metainfo for your map and reduce functions.
2. For each data point, encode it into your homomorphic ring, feed your map circuit both the input and the meta info to obtain a value suitable for reduction.
3. In a balanced binary tree (or other balanced arrangement to minimize tree height), apply your reduction operation to the output from your circuit and any encrypted map metainfo.
4. Hand the result over to the client for decryption

Answer 3

You might be interested in viewing Bruce Schneier's rather resoundingly negative take on homomorphic encryption at:

http://www.schneier.com/blog/archives/2009/07/homomorphic_enc.html?nc=11

Answer 4

Here's a wild shot in the dark:

We're thinking about protecting the plaintext from the person doing the computation on it. But what if the objective was to protect both the plaintext AND the algorithm?

Take, for example, MRI machines. The most expensive part of the MRI machine is the algorithm in which the machine analyzes the magnetic resonance data. Because of this, they are heavily protected by hardware devices designed to destroy the program before allowing itself to be examined by an untrusted party (or anyone for that matter).

If an MRI maker could centralize MRI data computing, it would be a fantastic reduction in risk of losing their algorithm. However, laws prevent them from accessing private patient data.

So! Homomorphic encryption allows this to happen where the patient data and the algorithm are both protected. The 'fully' homomorphic encryption (i.e. inducing a ring homomorphism onto the encrypted data) allows for a much more efficient and robust set of computations to operate on the data.

Answer 5

Electronic voting is indeed a practical application of homomorphic encryption, i.e. http://heliosvoting.org/

Answer 6

The problem with the existing homomorphic encryption algorithm is that you can only execute a polylogarithmic (NC1) circuit with it, which rules out almost anything interesting algorithmically.

Plus it doesn't seem that the complexity of encoding is in any way lower than the complexity of executing the polylogarithmic circuit yourself, so you haven't picked up any free work at first blush, unless you do something particularly tricky with it.