
IBM completes successful field trials on Fully Homomorphic Encryption - Nitrolo
https://arstechnica.com/gadgets/2020/07/ibm-completes-successful-field-trials-on-fully-homomorphic-encryption/
======
cs702
Fully homomorphic encryption (FHE) looks to me like the WET DREAM of every
business that wants to _control the software and content_ on your hardware
without ever having to decrypt sensitive code or data residing on that
hardware.

That's because FHE-encrypted software is _locally unhackable_ as long as its
implementation of FHE remains unbroken.

Think:

* FHE-encrypted mobile operating systems, applications, and data.

* FHE-encrypted desktop and server operating systems, applications, and data.

* FHE-encrypted "smart home" devices -- from light bulbs to dishwashers to fridges.

* FHE-encrypted transportation infrastructure -- from automobiles to trains to airplanes.

* FHE-encrypted industrial machinery of all kinds.

If FHE ever becomes practical, we're looking at a _very unhackable_ future.

Remarkably, I've never seen this issue mentioned anywhere else before.

~~~
josh2600
FHE gets brought up all the time. There are great discussions down thread
about why this isn’t practical for most use cases.

The killer thing is the performance penalty for doing FHE on any dataset of
meaningful size. This is because if you want to do an operation on one member
of the set you need to do an operation on all members of the set otherwise you
leak which member you care about. For sets of a very small size this
performance penalty might be ok. For sets of a large size, like the set of all
users of a service, the performance penalty will grow at least linearly to the
size of the set.

This is the problem at the core of ZK-style proving systems. You can push the
proof construction work into the client and have a sub-linear verification
time relative to the proof, but the proof construction in the first place is
going to be slow and expensive (and slower as the size of the set increases!).

The edge of research here is being done by cryptography labs all around the
world. If someone does manage to solve this in a purely-software based manner
with a performance penalty that is acceptable for a monotonically increasing
set, that’s the holy grail. I remain unconvinced that this will be solved in a
reasonable fashion for this use case in my lifetime (but I would be thrilled
to be proven wrong!!). If you know of research which makes inroads on this
problem, please point me at it.

~~~
cs702
Agree. That's why I wrote, "If FHE ever becomes practical..." \-- because at
present it isn't.

Currently it's a wet _dream_ for a lot of businesses.

~~~
josh2600
FHE style systems are possible if you use a hardware-based encryption approach
like a Secure Enclave, but then you have a trust narrative that includes a
Secure Enclave. For most use cases this is unacceptable.

Note: I work on a system design that I believe is acceptable that uses Intel’s
SGX which we detail in this tech talk entitled “why sgx”:
youtube.com/watch?v=Hwf_Q31woLo&utm .

~~~
ezVoodoo
If you believe in a Secure Enclave then there is no need for Fully Homomorphic
Encryption anymore as all the computation can be carried securely in the SE.
The question is the SE is not trustable for many people.

~~~
josh2600
It’s more complicated than “do you believe in SE”. There’s a difference
between using a SE for storing durable secrets (a bad idea in most
implementations I’ve seen) and using a SE for provably destroying a piece of
information. The former means that a break is full jackpot, the latter means
that a break compromises the system for a window in time and forward secrecy
can be restored with a patch.

------
giomasce
The comment by "Ibmresearcher" says that:

> Once one can do multiplication and addition all other operations can be
> bootstrapped from there so you can indeed do anything a Turing complete
> computer can do.

This is apparently iterated on many articles about FHE, but it seems false to
me: to do Turing-complete stuff you also need comparisons, and the ability to
change your flow depending on comparisons. But clearly you cannot do that with
FHE, otherwise you could extract the encrypted content, one bit at a time.

My understanding is that an FHE computer can only execute a fixed net of
additions and multiplications (or whatever operations they've got). So you can
emulate an "if" clause by computing both branches and then selecting one of
the two multiplying by 0 and 1 appropriately; you can do bounded "for" loops
always executing the maximal number of times, but you can't do unbounded
loops, therefore bye bye Turing completeness.

Of course there are a lot of interesting algorithms that can be executed
without being Turing complete, but the general statement is false. Am I
missing anything?

~~~
_trampeltier
Code might finaly look like with movfuscator (MOV on a intel processor is also
turing complete).

~~~
SilasX
Movfuscator only works because x86's MOV is like the Swiss Army knife of move
instructions. It doesn't just copy bits from one location to another, but has
parameters for conditionality and arithmetic, which is what allows it to be so
general. That still doesn't address the parent's confusion (that I share) of
how you get Turing-completeness just from addition and multiplication.

~~~
dlubarov
True, but there are simpler (abstract) machines that also achieve Turing
completeness: [https://en.wikipedia.org/wiki/One-
instruction_set_computer](https://en.wikipedia.org/wiki/One-
instruction_set_computer)

> That still doesn't address the parent's confusion (that I share) of how you
> get Turing-completeness just from addition and multiplication.

I wouldn't say arithmetic circuits are Turing complete since they can only
perform bounded computations, but we could say that they're functionally
complete. It is known that boolean AND and OR gates are functionally complete,
and we can reduce them to multiplication and addition in any finite field:

    
    
        x and y = x * y
        x or y = ¬(¬x and ¬y) = 1 - (1 - x)(1 - y)

~~~
giomasce
What does "functionally complete" means for you?

~~~
dlubarov
Informally, I mean reducible from time-bounded Turing machines. Given a Turing
machine TM and a time bound T, a (binary or arithmetic) circuit can be
constructed to simulate TM for T steps. Or in other words, a circuit can be
constructed to solve any particular instance of FNTIME(T).

------
Jabbles
But just 2 months ago there was an article on HN that stated:

 _The database is a key value store prepopulated with the english names of
countries and their capital cities from the continent of Europe. Selecting the
country will perform a search of the matching capital. On a 2019 Macbook Pro
laptop, the example searches take under 80 seconds._

[https://news.ycombinator.com/item?id=23435305](https://news.ycombinator.com/item?id=23435305)

And today this article claims _only_ a 40x compute cost for "machine
learning"?

What is the cause of the disparity?

~~~
miohtama
My layman guess is that the FME penalty goes up exponentially to the
complexity of an operation.

~~~
SahAssar
Doing a exact string match on 200-ish rows in 80 seconds on a modern computer
is so inefficient that I have a hard time seeing any less complex but useful
operations whatsoever. Perhaps I'm just not clever enough, but for now
homomorphic encryption seems like it isn't useful for common, real world
usecases to me.

------
bfuclusion
Someone please correct me if I'm wrong, wouldn't this still be vulnerable to
side channel or pattern analysis attacks? Also, how can all operations on a DB
like projection, and equality be represented by addition and multiplication?
Are we in the peano arithmetic space here? Can somebody break it down from me?

~~~
kmeisthax
You answered your own question accidentally: side-channel attacks are not
possible in this model of computation because everything is represented as
addition and multiplication. The homomorphic ciphertext doesn't tell you when
it's done, you sort of just do all the operations you're told and hand back
the answer gaining no knowledge about the computation you just did.

That's not to say that a badly-designed usage of homomorphic computation can't
_introduce_ a timing channel, though. If there's a point in time where the
result is handed back to the client, they inspect it, and then conditionally
send more computations, you might be able to infer something with either the
client's timing or if they happened to send back more computations or not.
However, that assumes that we'd be able to trace multiple API requests
associated with the same data set (as opposed to unrelated computations), and
that we know enough about the computations we're being told to do to infer a
timing channel from them. That's why I use the qualifying term "badly-
designed", which in practice will probably be most uses of this technology.

~~~
bfuclusion
So basically I tell you to do a bunch of stuff and give it back, and you have
no idea if the computation is a partial application/full application etc.
Neat. Next question: if my previous statement is correct it seems that it may
push a lot of the work back onto the client, otherwise I don't get how a
server couldn't figure out relationships from access patterns on blocks. This
would limit the utility of the server right?

~~~
dodobirdlord
Yea, fully homomorphic querying of a database necessarily requires reading all
of the data, or you could glean information from the access pattern.

~~~
josh2600
You can get a lot of the benefit of a linear scan using a technique like
oblivious RAM but I’m not convinced it’s possible to build such a system
without using a Secure Enclave. There are some papers that purport to
implement this but once you’re dancing in the realm of Secure Enclave’s you’re
out on a different limb.

I don’t think it’s possible for a circuit to operate over a large set quickly
and use a fully homomorphic pure software design.

~~~
Ar-Curunir
With some minor interaction between client and server, you can use ORAM in
conjunction with FHE to enable sub linear database scans. It’s not practical
for deployments, but is probably feasible for implementations

~~~
josh2600
I’m not convinced you can do ORAM without a Secure Enclave. If you’re already
using an enclave, you don’t need FHE.

------
skissane
> Above, we can see charts indicating the additional compute power and memory
> resources required to operate on FHE-encrypted machine-learning
> models—roughly 40 to 50 times the compute and 10 to 20 times the RAM that
> would be required to do the same work on unencrypted models

Are those multiplicative factors specific to machine learning tasks, or is it
the same for general purpose computation?

In other words, is there something about the structure of machine learning
tasks which makes them more suited for FHE than other computing tasks?

~~~
dodobirdlord
> In other words, is there something about the structure of machine learning
> tasks which makes them more suited for FHE than other computing tasks?

Yes, FHE is not (currently) good at general-purpose computing. Complex
conditional logic for example is a non-starter because every branch has to be
evaluated. But tensor multiplication is well supported with existing FHE
schemes, and many kinds of machine learning tasks consist of non-conditional
tensor multiplications.

~~~
skissane
> Complex conditional logic for example is a non-starter because every branch
> has to be evaluated

Is overcoming this limitation of FHE anywhere on the horizon?

~~~
dodobirdlord
No, it's pretty fundamental. If the executor were able to know which side of
the branch to execute it would mean the executor knows the value of the
conditional.

~~~
skissane
So [1] claims "A variant of fully homomorphic encryption scheme for Turing
machines, where one can evaluate a Turing machine M on an encrypted input x in
time that is dependent on the running time of M on input x as opposed to the
worst-case runtime of M".

I admit understanding this paper is a bit beyond me. But, does their
construction evaluate Turing machine conditionals by evaluating both branches?
If it did, how could the running time be "dependent on the running time of M
on input x as opposed to the worst-case runtime of M"? It seems to me that
having to evaluate every branch irrespective of the input would result in the
running-time always being M's worst case, not varying runtime depending on the
input.

[1]
[https://eprint.iacr.org/2013/229.pdf](https://eprint.iacr.org/2013/229.pdf)

~~~
dodobirdlord
I think this is a different approach to FHE that concedes to timing based side
channels to get this speedup.

------
sebmellen
I found the comment at the bottom of the page from the "Ibmresearch" user
helpful in understanding FHE.

To quote his TLDR:

> TLDR Huge polynomials are what are operated on instead of plaintext values
> by hiding the real data in the polynomials with intentional noise to make it
> infeasible to extract the real data without the decryption key that knows
> how to remove it. All operators are bootstrapped from addition and
> multiplication and elegant modulus trickery. Noise is managed at each
> operation because the noise compounds with every logic operation you do. The
> result of an operation chain or circuit be it one operation or infinitely
> many, therefore, has some noise but can be decrypted by the person with the
> encryption key. The decryption effectively drops all the noise and hones in
> on the bits that matter. The person doing the computation is doing a lot of
> adds and multiplies on big polynomials so they cant understand what you are
> really trying to do.

------
yalogin
Is there a recent breakthrough in FHE? The last I checked its no where near
practical.

------
forty
> With SEV enabled, an operator who has root privilege on a host system can't
> inspect or meaningfully alter the contents of RAM in use by a virtual
> machine running on that system.

Is that true? I would like to know more on what kind of garanties SEV gives /
how it works high level, any resources you can recommend? I assume that at
least when the VM is being launched, the sysadmin can mess up with the VM?

~~~
hannob
It is true if you assume SEV has no sidechannel vulnerabilities and that noone
can uncap your CPU and read out the cryptographic material with an electron
microscope.

Which both are probably untrue assumptions :-)

------
datafatmunger
I think this is exciting stuff. We're actively building prototypes around FHE
concepts. Basically asking the question: "Can we make meaningful care and
hospitality predictions, without ever seeing sensitive data?"

We've banged out some stuff with HElib, and some other interesting
implementations, but are just beginning.

And we're hiring for both backend and data science positions. :)
jobs@theembassies.com

~~~
gumby
But how much slower? At what cost?

------
jellyksong
The article claims that oblivious query, set intersection, and machine
learning on private data are not possible without FHE. However, aren't they
all possible either with secure MPC or hardware based enclaves e.g. AMD SEV?

~~~
Taek
I would argue that secure enclaves do not exist in practice. You have to
assume a physical device where the private key cannot be extracted and the
operation cannot be observed. The threat model is much weaker than for FHE,
and imo not really useful for operating in large sets of private data.

MPC introduces a trust assumption. MPC is only private if some threshold of
the multiple parties are honest and destroy their secrets. Though often this
threshold is just one, efficient MPC often only has 3 participants total.

FHE gives you a better security model than either of these, as it neither
relies on physics for safety nor needs to assume any level of honesty from the
person running the computation.

~~~
Ar-Curunir
In many MPC schemes you only need to trust yourself; as long as you keep your
stuff private, nobody can learn the MPC secrets

------
ackbar03
The extra computational power requirement is still pretty large... The math
behind it doesn't seem to be anything new, there's a reason why these
solutions aren't very commonplace yet

------
totetsu
Is anyone working on this for contact tracing? if encrypt( my_long_lat, PK ) -
encrypt( your_long_lat, PK ) <= 5m; raise_alarm

------
blamestross
Reminder, FHE not being Turing complete isn't important. Every computer ever
built has a finite memory and isn't technically Turing complete.

------
bookofjoe
[https://eprint.iacr.org/2019/1113](https://eprint.iacr.org/2019/1113)

------
unstatusthequo
Just in time for the EARN IT Act. :P

~~~
suizi
Even if it worked, I wouldn't want the government scanning through data for
whatever they decided was subversive or suspicious through undefined filters
and unaccountable agencies.

------
mindhash
If this works, see a huge impact on federated learning or training of NNs in
general

------
sabujp
this still isn't making sense to me, is there a simple math example of how
this is even possible if encrypt(1) = a, then how can encrypt(1) + 2 ever give
me the correct answer?

~~~
wbhart
You need encrypt(1) + encrypt(2). You would not be sent instructions to add 2.
No information about what you are doing is sent, except the operations + and
x.

As the comments in the article state, it's actually all done with operations
on polynomials with encrypted coefficients. As + and x can be done on
polynomials, it all works out.

The maths behind it is of course much more complicated.

As for a simple maths analogy, consider adding 1 + 2.

I'll encrypt your values by multiplying by 3 mod 7. So encrypt(1) = 3x1 mod 7
= 3 mod 7 and encrypt(2) = 3*2 mod 7 = 6 mod 7. Only the encrypted values are
sent, along with the operations I want to perform on the values.

Now this scheme is homomorphic, as I can just add the encrypted values,
encrypt(1) + encrypt(2) = 3 + 6 mod 7 = 2 mod 7. That is the only computation
that would be done before sending back the result.

To decrypt it, I would have to divide by 2 mod 7 by 3, which gives me 3 (you
can easily check that encrypt(3) = 2 mod 7). And indeed 1 + 2 = 3. So the
decrypted answer is correct.

Of course this scheme is too easy to crack. The FHE scheme is not.

~~~
sabujp
3 mod 7 + 6 mod 7 = 9

i think you meant divide by 3 mod 7:

9 / 3 mod 7 = 3

~~~
wbhart
Yes, I meant divide by 3 mod 7.

------
RcouF1uZ4gsC
> roughly 40 to 50 times the compute and 10 to 20 times the RAM that would be
> required to do the same work on unencrypted models

Too bad Moore's Law is dead, otherwise it would have been possible to run
everything we run now in 10-12 years using Fully Homomorphic Encryption for
the same cost!

~~~
giomasce
To me the practical problem with FHE is that, if it costs 20 times doing the
equivalent non-encrypted computations, it is cheaper to do it on your premises
rather than rent 20x the same computational power from a cloud host, unless
the cloud host is able to provide computational power at 1/20 of the cost it
has for you (which seems too much to me).

------
vbezhenar
IMO a more practical approach would be to use ordinary encryption inside a
CPU, so it wouldn't be possible to extract any data without extremely advanced
methods.

Rough description: CPU have secure memory which contains a private key. Also
CPU have certificate with corresponding public key. That certificate is signed
by Intel.

Hosting provider publishes an API which allows remote user to communicate with
that secure CPU, basically just transmitting encrypted stream to and from CPU.

When you're starting your communication, you establish an encrypted link
between your machine and target CPU, located in a data center. You can check
authenticity of that CPU by checking certificate signature. Then you're
sending any code you would like to execute (encrypted by session key). CPU
executes that code. It encrypts RAM in process, so it's not possible to read
its contents. And sends back some information (again, encrypted) which you're
interested in.

So you have computing resources which are protected from anyone except very
few who could extract private key from secure chip. I think that this kind of
protection should be enough for many uses. And it would not compromise on
performance. The only real world issue would be side channel attacks.

~~~
milkey_mouse
You're essentially describing AMD's SEV[1] as mentioned in the article. It
piggybacks on the memory encryption implemented in the Zen architecture by
giving a separate key for each VM. Ostensibly, the host can't interfere or
snoop in the VMs, assuming you trust AMD. I'm surprised it hasn't been more
widely adopted.

> protected from anyone except very few who could extract private key from
> secure chip

The way I understand chip manufacturing it would be hard to diffuse a separate
key into each chip. This means it'd only take one of those very few people to
extract and leak the key (or cut out the middleman and leak it from inside
AMD) to break it for everyone.

> The only real world issue would be side channel attacks.

This is probably a much bigger problem in practice. Spectre & related attacks
have been effective against Intel SGX[2], another "trusted environment" inside
a larger system.

[1]: [https://developer.amd.com/sev/](https://developer.amd.com/sev/) [2]:
[https://arstechnica.com/gadgets/2018/08/intels-sgx-blown-
wid...](https://arstechnica.com/gadgets/2018/08/intels-sgx-blown-wide-open-by-
you-guessed-it-a-speculative-execution-attack/)

