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

As a PKI geek, if the homomorphic cryptofunction were also an assymmetric key system, then you have some really interesting possibilities in the world of signing. The signer could potentially sign the message and a recipient could retransmit part of the message and the corresponding part of the cipher text to a third party.

In function notation, that would be:

User Signs:

sign(plaintext, private key) = ciphertext

and transmits:

send(plaintext, ciphertext, certificate)

Application gets segments:

plaintext = desiredPlaintext + otherPlaintext

and calculates the same conversion of ciphertext, using something like:

if ciphertext::plaintext then ??::desiredPlaintext

to find desiredCiphertext

Application forwards desired content only to external service:

send(desiredPlaintext, desiredCiphertext, certificate)

And the service can verify this message as though the user had sent it directly.

This depends on the hash algorithm used to compress the plaintext also being homomorphic. If not, this isn't going to work... or that no hash algorithm is applied.

This could be very useful in cases where you want an external service to do something in response to a signed user request, but you don't want to expose everything the user sent to that external service.

One example would be a simple package ordering system - I send a web app a request to buy a collection of items. To be super-secure I sign a Purchase Order that confirms that I want (and promise to pay for) some # of items, shipped to some specific location, by some specific date, and with some specific payment information. Now.. the web app will want to have several things happen:

• Finance needs to charge my account, and start getting a payment from me
• Inventory needs to pull the items from stock, or deal with any out of stock problems
• Shipping needs to receive from inventory and move the stuff to my address

There's no reason for Inventory or Shipping to know about how I pay my bill. And there may be no reason for finance to know my shipping address... In each case, the desiredPlaintext and desiredCiphertext changes, depending on who the receiver is. This is even more potent in a system like Amazon.com used books where the entity I bought from (Amazon) is different from the entity providing the item (the used book seller).

Reading the paper about lattice cryptography, it sounds more like a symmetric key system... which isn't so conducive to signing messages.

On the concept of "never say never", I'd not say it was unreasonable to use it for privacy applications. But it seems distinctly troublesome that you can find multiple ways of getting from ciphertext to plaintext.