🔐 FHE offers a way forward for data protection, ensuring security during computation. Our CACM review explores the future and the road ahead: https://dl.acm.org/doi/10.1145/3572832

🤝 Join the conversation & help shape a secure digital future! #data #encryption #FHE #privacy

Homomorphic encryption is the idea to arrange computation in such a way that, if fed encrypted input data, it will produce an encrypted result, and even if an attacker observes every bit manipulation the machine does, they will not be able to gain any information about the unencrypted input or result data.

Ideally, we would simply write a program, which a compiler would transform into homomorphically encrypted code for us. To date, there is no practical scheme for doing this, and there are reasons to believe that there may never be a way to do this in general. But there are some subtle details. Let me explain.

There is a somewhat simple scheme for homomorphic encryption which works, but there is a catch. First you need to blow up the input data exponentially, so that enough variants are produced, and the attacker is confronted with the problem that he cannot tell which of these are real data and which are just garbage.

But that's not enough! When running the program, the machine will also need to compute every possible conditional branch! Whenever there's an `if` in our program, the required computational effort doubles!

This cost explosion makes it completely impractical for almost all forms of data processing, like for example database applications, or even most patterns of communication, let aside any computationally more intensive workloads or, well, basically anything we use computers for today!

However, it may be feasible, perhaps, even if just barely so, for some cryptographical applications operating on tiny chunks of data. You'd still have to pay a hefty price for the blow-up, but it could be done. I mean, I fail to come up with ideas here, but maybe someone among you is able to imagine a scenario where this could be useful today, of course, given the limitations I mentioned.

So, it's pretty much theory, interesting as a subject for research, but not very useful. So what is cutting edge today? Here is a cool blog post by **Jeremy Kun** about the latest FHE compiler from google labs (of course, FHE means full homomorphic encryption):

https://jeremykun.com/2023/02/13/googles-fully-homomorphic-encryption-compiler-a-primer/

They implemented a compiler which takes a subset of C++ and generates logic gates. As to be expected, the subset of C++ is severly limited, here's how Jeremy puts it:

> A few limitations result from this circuit-based approach, which will be woven throughout the rest of this tutorial. First is that all loops must be fully unrolled and have statically-known bounds. Second, constructs like pointers, and dynamic memory allocation are not supported. Third, all control flow is multiplexed, meaning that all branches of all if statements are evaluated, and only then is one chosen. Finally, there are important practical considerations related to the bit-width of the types used and the expansion of cleartexts into ciphertexts that impact the performance of the resulting program.

Typically we'd expect a general purpose language to be _Turing complete, at least in theory. Some languages don't quite achieve that kind of generality and are only _primitive recursive_. SQL is such an example, it does not have unbounded while loops with which one could search for an object satisfying any given mathematical constraint. The Ackermann function is an example which is not primitive recursive.

The latter sounds a bit like what Jeremy describes, but his fragment of C++ is much more restrictive: We have to bound the number of operations by a constant before even looking at the data! A primitive recursive program may escalate its computation time quite considerably based on its input.

Okay, that's all theory, in practice, every program running on a physical machine is bounded, because it only has a limited amount of memory, and because we, its operators, won't have arbitrary amounts of patience before aborting what is obviously a crashed program. In fact, our limits on what we see as feasible are so tight, that the afforementioned exponential blow up still makes FHE wholly unattractive.

But wait, why does this research compiler produce logic gates instead of assembly code?

Well, that's the cool thing about this research. Assembly could be used, but logic gates have an essential advantage: There are well-known and rather effective optimization techniques for logic gates! And the speedup gained in this context really is impressive. The article doesn't go into too much detail, but if you search for optimizers for logic circuits you should find lots of fun literature about this stuff!

Still, by far not sufficient to make any of this practical, but interesting nonetheless!

#homomorphicEncryption #FHE

Royal Society of London issues a new report on Privacy Enhancing Technologies.... #mpc #fhe

https://royalsociety.org/-/media/policy/projects/privacy-enhancing-technologies/From-Privacy-to-Partnership.pdf

Anyone know a good starting point for fully homomorphic encryption for someone who doesn't have a math degree?
#FHE #homomorphic

A modest proposal for reforming #academic #PeerReview:

In peer review, it's standard practice for authors to not know the identities of reviewers. (In my areas at least) it's increasingly common for reviewers to likewise not know the identities of a manuscript's authors. This level of #privacy and #anonymity helps to protect reviewers from retaliation over negative reviews, and aims to reduce bias reviewers may form based on authors' identities.

I posit that that we should go much further and protect the plaintext of papers from reviewers to prevent them from forming opinions based on the manuscript's contents. I propose that we use modern #cryptography, specifically Fully Homomorphic Encryption (#fhe), to enable this evolution. FHE allows computation on encrypted data without exposing the plaintext to the party that specifies the computation or the party that executes it.

My proposed method is simple: authors encrypt their papers before submission, using keys known only to them. Reviewers submit functions (formally: circuits) that compute accept/reject decisions. Using FHE, the decisions can be computed over the ciphertext of the papers, without ever decrypting them.

Fully Homomorphic Peer Review (FHPR) would preserve many aspects of the existing peer review system:

* While FHE is time consuming and inefficient, computation for FHPR can be scheduled as low-priority batch jobs on already-oversubscribed resources. This follows the current standard practices for scheduling workloads for traditional peer review.

* As with actual reviewing criteria, reviewing functions do not need to be complex, making them easy to create. Libraries to check for the presence or absence of buzzwords and for citations to the reviewer's papers could further simplify function creation. To reduce the computation complexity of reviewing loads, reviewing functions can make their decisions based on the title and the first few sentences of the abstract.

* Encrypted reviewing functions give reviewers plausible deniability with respect to the actual criteria the reviewer used in decision making, a property shared by many written reviews.

* Reviewing functions are portable: since reviewers rarely adapt their criteria over time or to suit specific publication venues, they can create a single function at the start of their careers and re-use it indefinitely.

* Highly-optimized reviewing functions can be independent of both the plaintext and the ciphertext, providing ample opportunities for additional optimization and pre-computation of results. More research is needed.

* It seems unlikely that lack of access to plaintext will significantly alter the probability that reviewers read the paper, nor their understanding of it should they chose to do so.

In conclusion, we have met the enemy, and they are us.

Three days to submit your work and present during the http://FHE.org conference 2023 in Tokyo.

Read the official Call for Presentations here: https://fhe.org/conferences/conference-2023/call-for-presentations

#fhe #realworldcrypto #homomorphicencryption

Very nicely written article on how homomorphic encryption works -- https://bit-ml.github.io/blog/post/homomorphic-encryption-toy-implementation-in-python/

#encryption #fhe #homomorphic

RT @randhindi@twitter.com

We are open sourcing our @zama_crypto@twitter.com homomorphic cryptography library in september. Anybody from the @rustlang@twitter.com community interested in taking an early look? #rust #fhe #privacy #opensource

🐦🔗: https://twitter.com/randhindi/status/1280947692991131650