
Practical homomorphic encryption over integers (2017) - hamilyon2
https://arxiv.org/abs/1702.07588
======
guiomie
This is one of the current 'tech' trends that I'm following, the idea of
homomorphic encryption is really cool. I feel like there is a lot of real
world applications for it, but I have failed to find them yet.

~~~
jerf
I really want to sarcastically say "blockchain homomorphic encryption", but,
well, it's not necessarily a terrible idea, honestly. One can imagine some
combination of the primitives in which you could prove that you added here the
same amount you subtracted from there, that neither total is below zero, but
for which the number actually transferred is encrypted. The current use case
for something like BitCoin is often security focused, but there's also simply
a privacy concern that could be addressed there.

~~~
mhluongo
Hey, we're working on blockchain "somewhat homomorphic encryption" (SHE) via
multiparty computation. In particular, a privacy layer for Ethereum.

~~~
girvo
I implemented this, on top of Fabric however, and with a semi-trusted
controller node, for a rather large industry. Was a lot of fun, and is being
used in production. You can get quite far with SHE.

------
CiPHPerCoder
Homomorphic encryption is cool, but it's not the sort of thing most developers
will want to use in their apps. Most cryptography failures (BEAST, CRIME, the
Apple iMessage attack, etc.) that allow plaintext recovery are the result of
chosen-ciphertext attacks.

You want _authenticated encryption_ instead. [https://tonyarcieri.com/all-the-
crypto-code-youve-ever-writt...](https://tonyarcieri.com/all-the-crypto-code-
youve-ever-written-is-probably-broken)

You can sort of build something authenticated on top of a homomorphic
cryptosystem, but it's kind of a hack:
[https://paragonie.com/blog/2017/12/assuring-ciphertext-
integ...](https://paragonie.com/blog/2017/12/assuring-ciphertext-integrity-
for-homomorphic-cryptosystems)

~~~
williamscales
It's not something most developers will want to use in their apps for
application security, but it is absolutely something that folks may want to
use when training machine learning models based on customer data. As I
understand it, this is one of the big "pie in the sky" goals for homomorphic
encryption—having an encrypted model trained on encrypted data that only the
customer can use for inference.

------
shry4ns
What exactly is homomorphic encryption?

~~~
bo1024
You encrypt some data and send it to Bob.

Bob does some computations on the encrypted data and sends you the (still-
encrypted) results.

You decrypt the results to get the answer of your computation. Bob never
learns what your data is or what the results are.

The term "homomorphic" roughly refers to the fact that the encrypt/decrypt
functions go "outside" the computation. That is, if Bob is applying the
function f, we have f(Encrypt(data)) = Encrypt(f(data)). The left side is what
Bob does, the right side is what you want to get (because you can decrypt it).

EDIT. To see how cool this is, think about this: I have two numbers, I encrypt
them to form long strings of gibberish. Then I have Bob perform the
"multiplication" function on the gibberish and send me the result, and I am
able to decrypt that to get the result of multiplying the original two
numbers. If that doesn't impress you, I send Bob my database of encrypted
emails, then ask him to do a string lookup for "chocolate", he sends me back
the set of matching emails without ever knowing what they say or what string I
looked for.

~~~
hossbeast
Does it generalize? Can you in theory perform any computation in this way?

~~~
jldugger
To the extent that computations are feasible, yes. There was a pretty big
paper like a decade ago proposing a fully homomorphic system. It was pretty
much impractical, running like a million times slower than native
instructions. I assume without reading that this post's paper reduces that
multiplier to hundreds of thousands.

edit: reading the abstract, it looks like they don't have a faster fully
homomorphic system, just some better results in the partial homomorphic
domains.

~~~
betterunix2
Actually the paper presents nothing; their security proofs make no sense at
all and the rest of the paper is not much better.

~~~
jkabrg
Wow. Explain?

~~~
betterunix2
Theorem 1 fails to specify what it means to "attack" the cryptosystem; it
seems to deal only with complete plaintext recovery. It is possible that an
attack can only recover a single bit of the plaintext, something which is not
handled by the proof.

Definition 1 is not really a definition; in particular it would not be useful
in a proof or logical argument. Likewise with Definition 2.

The authors claim that chosen plaintext attacks are not relevant; then they
claim in Theorem 3 that their system is secure against CPA. Over and over in
this paper the authors refer to the need to be CPA secure when the plaintext
has "insufficient entropy" so it is hard to understand why they would claim
CPA security is irrelevant.

The vector version of their scheme appears to be a lattice problem, but the
authors do not discuss lattice attacks that might be used against their
scheme. The authors state that it is "clear" that the security of the vector
version follows from the same arguments used for the integer version.

In the "FHE" section the authors do not actually construct an FHE scheme;
instead they have constructed some kind of garbled circuit scheme that uses
the encryption schemes proposed in the paper. No proof of security is given
for that garbling scheme.

For what it's worth, this is more or less what I would have written if I had
to review this for a conference and I would give this paper a "strong reject"
score.

