Thanks!.

]]>So where does the strange idea that it takes longer come from?

More problematic, it seems to me, is that any algebraist can decipher most kinds of homomorphism easily. If division is implemented in the arithmetic, one just has to try x/x, in encryption, for any encrypted x, to get the encryption of 1. Then one gets the encryption of 2 by doing the encrypted arithmetic for 1+1. Etc. So one constructs the code book in 2^32 steps.

Yes, I can defeat that, but you'd have to ask me!

If division were implemented as a software routine instead, then one would likely have good evidence for certain constants (0, 1, 2, ..) being embedded encrypted in the routine. And one could probably recognise the algorithm anyway and figure out which constants were in use where. Please correct me if you know better! All I can think of that _might_ defeat that is implementing Fourier's algorithm for modular division, but them one might as well do it in hardware.

And if one merely has " one less number than it is

So how would encrypted arithmetic defeat any attacker with less than an ounce of brains? Further defense is required (which I can think of, but I have never seen mentioned).

But all this about "takes longer" is just nonsense. DO people somehow imagine (falsely) that encrypted arithmetic is just done by sticking hardware codecs on the inputs and outputs of an ALU? That WOULD make it take longer, but it's a daft way to go. And I'm not even sure it would make thing stake longer overall, given that a processor is pipelined .. it merely needs to have thruput of 1 arithmetic operation per cycle, never mind how many cycles the operation actually takes .. 100 would be a bit much, but 10 would be fine. So long as one can do 1/10th of an operation per cycle as a single stage, then a pipeline 10 stages long for the operation would average one operation per cycle.

The last page of the article provided some example use cases.

]]>@Natanael :

yeah, you can do everything that is neccessary for statistical computations (mostly logarithms etc.) by using these approaches:

http://dx.doi.org/10.1109/WIFS.2010.5711458

and

http://www.springerlink.com/content/nr5433524x23/#section=1029574&page=1&locus=0

(Disclaimer: this is our work on secure two-party computations).

even better user passwords are used as keys in the sql proxy, so if the server is seized the only people compromised are those who are logged in (and have their key in the proxy).

it's still basically a research prototype but eventually they're going to release a full beta version

]]>All accounts remain anonymous and encrypted. The customer can still transact, adding and subtracting funds. Totals hash maintains data integrity and verifies completeness/accuracy. Cash/Asset pools back up the encrypted accounts and tie out at the summary level, but reveal nothing about the transactions.

Banker knows only that it has the money it should at an aggregate level, customer is the only one that can decrypt the account to the transaction level detail or make any transactions.

Transactions cannot be tied to an individual customer.

Thoroughly illegal in the US for that very reason: KYC

]]>I'm reminded of that old CS joke about the algorithm that correctly predicts the weather worldwide for the next 24 hours, but it take 3 days to run.

The application that comes to mind for me is smaller computations, instead of data-crunching. Like third-party decentralized authentication. (e.g. OpenID). If you could get OpenID to verify your identity for login purposes to a third party without having to even give them your personal details (only an encrypted version of them) and to log in providing an encrypted version of your key, it'd open some interesting doors.

]]>For pure computation like arithmetic - I can just use my own computer for that, and the overhead of homomorphic encryption would probably far outweigh any economies of scale that cloud computing might have.

The only kind of "computation" that I need someone else for is querying a database I don't have - for example, it would be nice if I could hand Google an encrypted search term and get encrypted results back without them knowing what I searched for. But a homomorphic system can't do database lookups without reading the whole database (if it reads only a subset, it's leaking information).

]]>"Homomorphic addition takes milliseconds, multiplication generally less than a second. These timings are a vast improvement over earlier efforts, but itâ€™s sobering to reflect that they are still an order of magnitude slower than the performance of the ENIAC in 1946."

And that's not even a fully homomorphic implementation. So it's going to take a solution that's orders of magnitude faster (quantum computing?) to make this viable.

]]>For example, imagine this: I have some data I want processed by a program, and I don't want the program to know what it is. The program author doesn't want me to know how the program works.

So I encrypt my data with my public key, and hand it to the program, which is run on my computer...the program processes it without the program ever being decrypted, and hands me back the processed data without ever knowing what the data was. I use my private key to decrypt the correct result.

@Curious: Being fully homomorphic is a fairly simple mathematical property, and it's a standard part of inventing a homomorpic cryptosystem that one *publishes* a mathematical proof that the homomorphism works, which anyone is then able to verify at his leisure.

Being *secure* against attackers is something completely different, which is hard to prove, except in relative terms by proving that anyone who is able to break the scheme would also be able to solve the underlying "presumed-hard" problem (approximate GCD), which is *thought* to be impossibly hard. But that is more or less the same kind of guarantees you get for public-key cryptosystems too, and symmetric ciphers usually don't have even that.

How can/could anyone know if an applied homomorphic encryption scheme is "fully" homomorphic and not something just just appear to be "fully" homomorhpic (being somethin else instead)?

I am simply guessing and sort of taking for granted that bad things could happen if there was no way to really know if a homomorphic encryption scheme is a "full" one or not.

My apologies if my question appear to be more of a meaningless question. It's not like I have an idea of how the math behind this is supposed to work.

]]>Anyone have any extra research grants lying about?

1PTxHjhrJDHmZqBD3rTEGjTvzmbECNF5Ku

]]>Multiplication and addition are great for DSP, but little else. Real-world algorithms involve decision making, boolean algebra, table lookups, etc.

True, the user may perceive nothing of value in the content they read or comments they post. Unfortunately, just such data is of enough interest to some that it's for sale or subject to subpoena.

]]>Oh no, that's "homophobic" encryption. Sorry :-)

]]>