
Homomorphic encryption - azujus
https://en.wikipedia.org/wiki/Homomorphic_encryption
======
KenoFischer
There is a decent size effort to build a system that runs (a restricted, but
hopefully useful subset of) Julia programs fully homomorphically (as well as
supporting various sort of secure multiparty computation protocols). At
JuliaCon two years ago, the Galois folks talked about their initial prototype
of this work:
[https://www.youtube.com/watch?v=_KLlMg6jKQg](https://www.youtube.com/watch?v=_KLlMg6jKQg)
(fun to watch even if you don't care about julia to see FHE "in action"). This
effort was recently funded with the goal of extending the prototype into a
full robust system, so I'm hoping for some good news here over the next couple
of years.

------
tuxxy
If anyone is interested in playing with Fully Homomorphic Encryption, we
(NuCypher YC S16) built NuFHE
([https://github.com/nucypher/nufhe/](https://github.com/nucypher/nufhe/)).
It's written in Python and has excellent documentation, so you can try
building some circuits and playing around with it. It requires a GPU to run,
but it's also the fastest implementation of FHE in the world (that I know of).

Let me know what you think! :)

~~~
Labo333
Is there some kind of interoperability with other libraries? Or does it
support CPU encryption / decryption ? For example, one can expect clouds to
have GPUs to perform computations but encryption and decryption are typically
done by clients on various devices where portable code is expected.

~~~
tuxxy
This is mostly a research library, so we haven't put our limited effort into
CPU operations yet, but it's definitely possible if someone wanted to take the
time to expose it in the library.

------
Iv
Seriously one of the most important area of mathematics for democracies in an
online world.

Homomorphic encryption promises a hidden and verifiable online voting system
that does not rely on trusting third party.

~~~
rfugger
Any political voting system will need a trusted third party to run the voter
registration/identity system, so I doubt the lack of practical homomorphic
encryption is blocking this. There are other voter-verifiable systems that
don't rely on HE for trustworthy counting:

[https://www.chaum.com/publications/AccessibleVoterVerifiabil...](https://www.chaum.com/publications/AccessibleVoterVerifiability.pdf)

The major problem with online voting is that people can be coerced into voting
against their wishes outside the watchful eye of election authorities. This
may be worth the increase in voting ease, but it's where the real debate is.

~~~
k__
How does online voting differ from mail voting?

The only difference I see, is, the mail is sent via the postal service and the
online vote is sent via my personal computer and internet connection.

To get around this, the government could issue verified voting tablets that
are locked down and use secured connections.

Otherwise, people can force me to vote different without the authorities
noticing already.

~~~
pessimizer
I don't know that there is a difference, and I'm finding the fact that it's
becoming more widespread a problem. There could already be a nontrivial number
of coerced or paid voters. Voting by mail should be a tiny percentage of the
vote, largely consisting of people who are overseas. Instead, we're starting
to see a lot of elections decided by mail-ins.

------
wish5031
If this interests you, a related concept with similar applications as HE is
functional encryption:
[https://en.m.wikipedia.org/wiki/Functional_encryption](https://en.m.wikipedia.org/wiki/Functional_encryption)

~~~
rudolph9
Here is a descent looking Haskell library that implements functional
encryption concepts
[https://github.com/cpeikert/Lol](https://github.com/cpeikert/Lol)

------
doctorpangloss
The technology for all this progress was a huge discovery in 2009. But what if
it is a dead end, that nothing originating from that discovery will ever be
practical?

Like wouldn't it be preposterous if someone said, "Here Craig Gentry, take $1
billion to run enough computers for the current FHE schemes. What is the
snazziest demo you can run?"

~~~
rhindi
Some of the newer schemes are much faster. The recent progress feels like deep
learning in 2010, right before everyone realized it worked

~~~
poz
> The recent progress feels like deep learning in 2010, right before everyone
> realized it worked

Does it work, though?

~~~
throwawaywego
[https://www.microsoft.com/en-
us/research/publication/crypton...](https://www.microsoft.com/en-
us/research/publication/cryptonets-applying-neural-networks-to-encrypted-data-
with-high-throughput-and-accuracy/) (2016)

> We demonstrate CryptoNets on the MNIST optical character recognition tasks.
> CryptoNets achieve 99% accuracy and can make more than 51000 predictions per
> hour on a single PC. Therefore, they allow high throughput, accurate, and
> private predictions.

------
ktta
A very casual (layman's?) introduction intro to Homomorphic Encryption -
[https://news.ycombinator.com/item?id=13450015](https://news.ycombinator.com/item?id=13450015)

------
bikeshaving
Why do people always talk about arbitrary computation in relation to
homomorphic encryption? What I really want is a homomorphic encryption system
which allows me to arbitrarily slice and concatenate strings without knowing
their contents. This would be immensely useful for implementing end-to-end
encrypted collaborative editing of documents. Is homomorphic encryption there
yet?

~~~
kradroy
I'm dying for this. My team builds ML models on text corpora. Most of this
data is sensitive. My company has very strict data privacy policies and it's a
pain to even share the data with other teams in the department. I've made it
part of my long-term goals to facilitate secure sharing of sensitive data
across the organization. Numerical data seems to be the easiest to anonymize
(randomized response, etc), but I have yet to find any techniques for text
other than generating synthetic data.

~~~
tuxxy
Hi, I've been replying to other people in this thread. I work at NuCypher
doing some research and cryptography engineering. I work on Proxy Re-
Encryption and Fully Homomorphic Encryption.

Do you mind sending me an email with your use case and needs? I'd love to have
a chat with you.

john@nucypher.com

~~~
drenvuk
This guy right here, this guy knows whats up. gl john.

------
buzzdenver
For a layman like me it sounds really cool, almost like magic. Consider a
trivial operation like finding a maximum value in a list. How is that supposed
to work on encrypted values while simultaneously providing strong encryption?
So something like adding N to everything in the list is not an acceptable
encryption.

~~~
tonmoy
Today is the first time I heard of Homomorphic Encryption so I have 0
knowledge about this. But just to show this is not magic, you can provide N*N
number of lists where each list has totally different results and then get the
max index for each list as a return. Since you know what original list was the
right one, you can keep that result and discard rest

~~~
buzzdenver
Not sure I'm following you. Would you transmit in plain text N-1 random lists
along with the real one? I would not consider that encryption.

I guess one brute force way to do it is making encryption unnecessary. For an
input of N bits, have the results calculated/returned for all 2^N
possibilities. Does not sound very practical.

------
rch
I've run into a few people working on this over the last five years or so, but
they've been a bit cagey about discussing their use cases and customers.

Any public applications outside of blockchain?

~~~
motohagiography
When I encountered FHE as a potential solution, it was in designing
authentication and payment tokens.

Use case was you need to be able to verify that the output of a program was
also a proof of the integrity of that program.

E.g. I receive a payment token from you, and I can verify that this token was
produced by a program I could verify as being the "real," program,
personalized to your identity, on a device also personalized to your identity,
that you physically hold and verify yourself to.

Pretty good* with a chip/pin combination, but on a mobile general purpose
computer with lots of other code on it, Hard problem. With some handwaving,
FHE would ostensibly have enabled the secure personalization of the program
and the signing of those token outputs. It was a variation on:
[https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation](https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation)
as well.

FHE was the DRM holy grail where suddenly you can "tokenize," information.
Other applications are in selling and metering software use.

In the case of health information, the ability to open up data sets to
researchers to query and analyze without the risk of losing control of the
data is huge. We know that de-identification of data is (information
theoretically) impossible, but an ideal FHE scheme would facilitate queries
against data that would mitigate much of the risk associated with it.

The other use case is in highly regulated environments where there are legal
firewalls between lines of business. Basically wherever there is a use case
for de-identification, FHE is a potential solution in that domain. In that
regulatory case, it's sort of ironic that it's a solution for, "ok, we won't
commit a crime, but we need the hypothetical output of that crime, so let's
use cryptography to facilitate that outcome without explicitly breaking the
law whose effect is to prevent this outcome."

Perhaps that's why people working in it seem so cagey.

------
crdrost
To address the inevitable “what is this useful for” questions, my go-to
example is cryptographic voting mechanisms.

The idea is that you segment a large integer into a couple of different bins
by its bitwise representation. So you have a 60-bit integer and you segment it
into four 15-bit bins. You use one of those to randomize what the encrypted
versions are going to be, and you use the other three for different vote
tallies of three candidates for some office.

You can then hand people three numbers each corresponding to a different
candidate, and ask them to commit to one as their vote. Public authorities can
then aggregate votes which they cannot actually see, and we don't decrypt
until we get to some large enough context where your vote has been anonymized
among ten thousand others, and you can check that the random seeds have been
properly added, or other such things.

This also allows you to create a big online database where anybody can see
their vote was counted, but nobody can figure out who someone else voted for.

There is a slight difficulty in that you cannot see directly what your numbers
are actually voting for, so that the machines you are using to vote with need
to be able to decrypt a ballot for you and then immediately destroy it, to
verify that it was what you thought it was, so that you can trust that your
three numbers do not all happen to vote for the same person because if someone
tried that on any scale that could affect an election, even if they only
poison 1% of ballots in a 500 person district, if everyone burns one to test
the system then the fraud gets discovered at least once with 99.3% certainty.
But the point is that all of these other issues can be handled “out-of-band”
once you protect the important stuff.

~~~
compsciphd
I'd think there's a simpler way to accomplish what you said above (though in
both cases, any voting mechanism that lets the voter verify their vote after
the fact also runs into the problem of people complaining about encouraging
vote buying).

i.e.

imagine every polling place would output to you (after you voted) a random
number in the 128 bit space.

the votes are recorded with this random number. we can verify after polls
closed that the voting machine has an appropriate number of votes (i.e. not
more or less than people who came through the booths)

all these vote data is aggregated into public record. you can look up after
the fact your random number and see that it matched who you voted for. No
encryption needed (beyond the technology that goes into making a secure rng)

~~~
crdrost
Well, no, if you do it cryptographically, at least with the proper mechanism,
you can prevent votes from being buyable. In your case, if someone wants to
buy your vote, they can ask you to text the number to them before it has
appeared as a matter of public record—and if you voted for the Right Person
they will pay you. The 128-bit number makes this very hard to forge, whereas
to destroy vote-buying you want to make something very easy to forge.

Suppose that you receive a ballot from a machine which tears it down the
middle: on the right hand side are bar codes containing the voting numbers; on
the left-hand-side are candidates' metadata—names, parties, etc. So from the
very moment I hand you the ballot, _you_ can see that there is a connection
between these numbers and those names, but as long as I provide a supply of
other left-hand-sides in other orders, it becomes very easy for you to fake it
when displaying it to someone else. That ease-of-forgery is the key to making
it impossible to buy votes.

~~~
compsciphd
maybe I'm missing something, but I can't see any system that allows me to
verify my vote after the fact not enabling a vote buying mechanism.

As I understand it (perhaps incorrectly), the primary thing that makes vote
buying financially difficult is the fact that a person's vote can't be
verified. how does homomorphic encryption enable me to verify my own vote but
prevent anyone else from using the info I'd give them that I'd use myself to
verify my vote.

~~~
crdrost
Just the way I said in the comment you are replying to. Well, actually, I know
two ways, that is just one of them.

Let me put it a different way. Let us suppose that you are in New York State
in 2016, voting for the US president, and let's ignore the strange things that
can happen with write-ins. After a random shuffle your ballot might look like
this:

    
    
                             | BALLOT #5846
                             |
        1. Hillary Clinton   |  [  ]  [barcode]
           Democratic Party  |
        2. Jill Stein        |  [  ]  [barcode]
           Green Party       |
        3. Gary Johnson      |  [  ]  [barcode]
           Libertarian Party |
        4. Donald Trump      |  [  ]  [barcode]
           Republican Party  |
    

As this ballot is being presented to you, it is being cut by a sharp blade
along that line through the center. So you have these two halves, and you know
that they once belonged to the same piece of paper.

The right hand side is scanned and it is what we make public. Everyone can
confirm that you voted in this past election, and you punched the third (say)
square in your ballot. But we also make it really easy for you to take,
outside of the voting booth, any of a number of other left-hand sides in other
random permutations. So if you wanted a left-hand side that said "Trump,
Johnson, Stein, Clinton" that is easily available for you to take out of the
booth.

Now after the election you can keep either or both papers and go to a
government-run website and confirm that that right-hand side corresponds to
who you voted for, and you can start a political watchdog group to make sure
that the homomorphic operations were properly done on all of these peoples'
right-hand-sides-of-ballots. But that web site is not saying "Oh hi it's you,
you voted for Gary Johnson," it's saying "Oh hi it's you, you voted for the
third person on your ballot." You know that the left-hand side you have says
that candidate #3 was Gary Johnson, you saw the paper cut with your own eyes.
But to everyone else, that left-hand-side is just a piece of paper.

So: we have made it very easy for you to forge any other vote, as far as any
other party would be able to verify. Nobody else can confirm the connection
between the piece of paper you hold in your hand and the piece of paper that
has been scanned and appears in the public database. And since this is very
easy to forge it is very valueless as a piece of information for vote-buying
purposes.

So that stuff is all really straightforward. The only dodgy thing is, what if
I were to hand you a ballot like this where every vote on the right hand side
happened to be a bar code for Jill Stein? Since the number is encrypted, that
is not something you would otherwise have access to.

And the solution there is burning ballots on-demand. You can make requests to
the election authority asking to decrypt a ballot during the election; indeed
we print a lot of extra ballots expecting folks to do this and we declare it
their civic duty. When you do so, you get to reveal the "true" left-hand-side
for a given right-hand-side and confirm that they are the same—but that ballot
is thereafter invalidated and cannot participate in the election. As more and
more people do this, it becomes more and more costly to do less and less vote-
rigging in this way. So you get an implicit assurance that no tampering has
happened in the process of getting this ballot to you, if you can trust that
your communication pipeline to the decryption authority is secure and they are
not compromised. (And if they _are_ compromised there is very little you can
do in any case.)

(The other mechanism just has a ballot which is two pieces of paper attached
above each other with labels on the one piece of paper and holes that let you
punch out the other piece of paper -- you can go online after the election and
verify that the hole which was punched was the one you punched, but your
ability to get other front-sheets at the voting booth makes it very easy for
you to forge a ballot for say your employer where you appear to have publicly
voted for their preferred candidate but secretly you voted for another one.)

~~~
compsciphd
re burning ballots.

If it's possible to burn a ballot (i.e. associate the set of bar codes to
actual candidates), shouldn't it be possible to "burn" a ballot after the fact
as well?

i.e. we have 4 barcodes, I need a way to associate each barcode with a
candidate to burn it, so why couldn't this happen after the fact as well?

I assume homomorphic encryption might help here, I just am missing it.

~~~
crdrost
Homomorphic encryption does not affect that problem... It's just down to
policy. If the decryption authority “stays open” after the election and no
longer insists on checking ballots to see if they have already been cast, then
yeah, you can abuse the system to decrypt placed ballots.

If the keys are destroyed after a valid election, as one would expect, then
there is no possibility for that.

One way to better ensure the keys are destroyed is to use secret-sharing
schemes so that multiple parties that are adversaries would have to lie
similarly about destroying the keys, then conspire to work together to decrypt
ballots after the fact. But I hope you see that this is all chasing social
problems that must be solved as a precondition to have fair elections in the
first place.

~~~
compsciphd
well, you would have to someone "close" the ability to "decrypt" the used
ballot instantly, otherwise while the election is ongoing someone could
"decrypt" it.

Though I tend to agree, its more of a social issue that technology can't
really solve and hence why I'm more concerned about a user (and hence others)
being able to verify that their vote was recorded correctly than doing out
utmost to discourage "vote buying" schemes as at the end of the day, I don't
think technology can really solve that problem but having more faith in the
electoral system as a whole by being individually verifiable has more value
(even if it can make vote buying more common). but I understand I might be in
the minority on that.

~~~
crdrost
Right, the protocol is essentially that you have a central server which
supports in essence two SQL queries,

    
    
        UPDATE ballots 
        SET status = "burned" 
        WHERE contents = :ballot AND status = "unused"
    

which, if it succeeds, then sends the ballot to the decryption oracle with the
private key, to be decrypted and sent back to the user; and

    
    
        UPDATE ballots
        SET status = "used"
          , voter_id = :voter
          , choice = :choice
        WHERE contents = :ballot 
          AND status = "unused"
          AND region = :region
    

which, if it succeeds, then sends back a confirmation that this user has been
logged with that ballot and made that choice for that ballot.

If you allow people to access the decryption oracle without going through that
first pathway, which simultaneously checks if the ballot was not spent and
immediately spends it into the "burning" pathway, then either of those opens
up the space to attacks which decrypt individual ballots. With that said, just
about any auditing mechanism applied to the decryption oracle would be
revealing the existence of those attacks anyway so you can still get a measure
of security without this.

You can potentially even distribute the database (e.g. over a blockchain among
several political parties), but as far as I can tell the decryption authority
would still need to be centralized and could be a single-point of failure. (In
this case it would be a program which is watching that blockchain and
interacting with it via some “I publish a burned ballot onto the ledger after
I think the blockchain has passed N blocks ahead of the ledger request to burn
that ballot” algorithm, and nodes in the network need to reject requests to
cast ballots that they think have been requested to be burnt.)

~~~
compsciphd
at the end of the day, this still relies on a heavy level of trust (i.e. on
the infrastructure itself to do the right thing and that no one has a copy of
the db).

As discussed, I'd prefer a system that increases trust without relying on
trusted components (by making the vote verifiable after the fact) even if that
can incentivize vote buying (but that's mostly because I view trusting the
infrastructure as a bigger threat than being worried about vote buying, but I
might be wrong about that)

~~~
crdrost
I don’t understand why you think these things are necessary or opposite.

You can have a system where everyone has a copy of the database. That is not
hard, it just requires the separation of what a ballot means, from what is
stored in the database. That is just these two-sided ballots with encrypted
values on the right-hand-sides: so that the fact that I voted for #1 on my
ballot does not tell those who hold the database who I voted for.

You can have a system where encrypted ballots are known by the people to have
the values that they say they have. That is not hard, it just requires a
challenge-response scheme. If I give you a box and claim there is a pony
figurine inside, you can be suspicious: if I give you twenty thousand boxes
and claim that they all have pony figurines inside of them, and you ask me to
open ten thousand of them which you choose randomly, then for me to omit one
pony I am facing a 50% detection rate, for two I am facing a 25% detection
rate; to disenfranchise even 10 people from their ponies I will be caught in
the act 99.9% of the time, and even then I can only disenfranchise 0.1% of the
boxes.

So I can have great confidence that my vote was recorded for the first person
on my ballot (I can see the database), and I can have great confidence that
the first person on my ballot was Alice and not Bob or Carol (because they
passed my challenge/response test).

You can also have a system where nobody can pay substantial sums of money for
votes. That is also not hard, it just requires the things that users take home
with them out of the voting booth to be easily forged, so that they cannot
prove that they did not forge the thing.

Absolutely none of this requires homomorphic encryption; homomorphic
encryption just streamlines some of the process around the decryption oracle:
with HE tallying and anonymization happen outside of it, so that its internal
structure simplifies drastically.

------
dustfinger
Could a fully homomorphic cpu architecture with fully encrypted cache be
immune to Spectre and similar side channel attacks? Could this be tested on an
FPGA?

~~~
tuxxy
Unfortunately, FHE doesn't work this way. You're operating on encrypted data,
so performing some branched operations doesn't work due to the security (IND-
CPA) security.

IE: You have a value that you need to do `if <condition> then <statement> else
<other statement>`

Problematically, if that condition could work, then it would violate the
confidentiality of the encrypted value, thus breaking the CPA security. Now
there are some workarounds and methods to getting around this problem
sometimes, but in many cases it's not possible.

~~~
ay
So any unit of work in the FHE scenario is necessarily a basic block with no
branching ?

~~~
tuxxy
In most situations, yes. Like I said there are methods and exceptions, but
it's complex to get into.

------
Nightshaxx
My school is working on this right now. Seriously awesome.

------
amelius
Are these schemes theoretically resistant against quantum computing?

~~~
rhindi
Yes, all the fully homomorphic schemes are lattice based and thus thought to
be quantum resistant

