Talk:Homomorphic encryption

Page Structure

I came to this page while searching for an explanation of "fully homomorphic encryption." While the explanation on this page may be rigorous, it is not understandable to someone untrained in the mathematics. Is it possible to include a brief explanation of the proof and the results for the non-specialist?

I suggest we restructure the page so that we begin with high-level overviews of homomorphic encryption in general, with earlier introduction of the FHE concepts and lattice-based crypto concepts.

Furthermore, the page, as currently written is highly mathematical. How about we restructure the page to provide more introductory material earlier. Any suggestion on how to restructure for improved usability?

Kryanr (talk) 13:55, 11 February 2019 (EST)

I agree. The page is organized in a very confusing way: partially homomorphic encryption schemes are presented first very concisely and mathematically, making them look intimidating and therefore important, whereas in reality fully homomorphic encryption schemes, presenter later in the article, are much more relevant today. Indeed, I would imagine that someone searching for homomorphic encryption is trying to find information about fully homomorphic encryption.

I suggest we:

• move the fully homomorphic encryption section before the partially homomorphic encryption;
• either add more explanation and motivation to the partially homomorphic section or remove it altogether;
• shorten the header paragraph and instead create a longer introduction section to explain motivation, history, and capabilities;
• add a section to the end about challenges in the field, e.g., "Critique" or "Issues";
• add clear examples of modern applications with links to supporting news articles and research papers.

--Kimlaine (talk) 17:49, 13 February 2019 (UTC)

I agree completely that homomorphic encryption is better served by starting with a general discussion and then moving to specialized approaches - perhaps starting with 1) an intro to the space of HE capabilities 2) a discussion of general FHE-based capabilities and then 3) specialized partial homomorphic capabilities.

I also think that some of the applications aren't completely relevant and we should look into trimming that material.

--Kryanr (talk) 16:05, 113February 2019 (EST)

Plain English?

Cyberpageman (talk) 13:54, 11 June 2010 (UTC)

Try http://www.mail-archive.com/cryptography@metzdowd.com/msg10571.html for a very high-level description, and then http://cacm.acm.org/magazines/2010/3/76272-computing-arbitrary-functions-of-encrypted-data/fulltext for a still reasonably high-level description, but with much more detail.

Le Grande Pamplemousse (talk) 18:54, 16 June 2010 (UTC)

I agree with Cyberpageman. The description of fully homomorphic encryption should be simplified to answer the most important questions up front. What is fully homomorphic encryption? Is there an implementation? (The phrase "The existence of an efficient and fully homomorphic cryptosystem would ..." suggests that fully homomorphic cryptosystems might not even exist.) What is the state of the art in FHE? How does it work in a couple sentences? The history of FHE could be addressed after these questions are concisely answered. I would like to see the part on the history of FHE modified to be accessible to a reader completely unfamiliar with the literature. I doubt this will work and I don't know how Wikipedia handles notifications, but I'd like to call on 128.32.36.227 if that's even possible since they seem to have started the section in 2009. I'll try to make some updates myself, too.

Erickspedian (talk) 14:23, 2 November 2017 (UTC)

Unfounded claims, work in progress, and advertisement?

In addition to the lack of plain English already cited, this article suffers from a number of other problems that make it inconsistent with Wikipedia principles:

1) Homomorphic encryption is very much a "work in progress", an area under active research. Parts of this article read like breathless news reports, albeit news reports on a very slow-moving story.

2) While there are references, other claims are made without support or citation, such as "enable widespread use of cloud computing" and "an efficient and fully homomorphic cryptosystem would have great practical implications" (hard to say why this would, when it is difficult to understand the subject; seems like an authority saying "trust me, this is so").

3) There is no specific "weakness" or "critique" section - everyone is presented as good news (or pretty good news or mostly likely to be pretty good news).

4) The page links to other articles of similar opacity, articles that may exist just to promote homomorphic encryption.

5) Why are there no links to cryptography portal or to the page on Homomorphism? (http://wiki.riteme.site/wiki/Homomorphism)

The article seems to read like a promo piece written by someone who understands the topic and loves the topic and wants us all to love the topic, but cannot be bothered explaining it to the rest of us, telling us how it relates to anything else, or what might be good and might be bad about it. — Preceding unsigned comment added by PeterWhittaker (talk • contribs) 14:41, 31 July 2011 (UTC)

Answering your third point: the weakness part is very technical, but someone could write things about the impossibility of obtaining a IND-CCA2 homomorphic scheme and that it is hard (nowadays) to find even IND-CCA1 schemes. Also, it is possible to write about the unusual assumptions, like the circular security one. Another drawback of homomorphic schemes is that they are very slow. But we do not know until know if it is a intrinsically property or if truly efficient homomorphic encryption schemes may happen some day. -- Lp.vitor (talk) 02:23, 15 June 2016 (UTC)

Fully homomorphic

The definition "Fully Homomorphic Encryption: We say that a homomorphic encryption scheme E is fully homomorphic if it compactly evaluates all circuits." from Gentry's thesis is supposed to distinguish a scheme of limited multiplicative depth (a somewhat homomorphic scheme) from a multiplicatively unlimited scheme rather than an algebraically homomorphic scheme, i.e. a scheme that supports addition and multiplication, from one that supports only one operation. In the current definition of "FHE" the somewhat homomorphic schemes would be already "fully homomorphic". — Preceding unsigned comment added by 91.43.122.207 (talk) 00:54, 13 December 2011 (UTC)

Anybody got any comment on this? Otherwise we should modify the article. — Preceding unsigned comment added by 93.199.37.153 (talk) 23:42, 16 December 2011 (UTC)

There may be a problem in the interpretation, an particular that calling the limited depth scheme being "somewhat homomorphic" may not be implying "not FHE", but rather "limited depth FHE", where FHE still refers to algebraic homomorphism. The concept of algebraic homomorphism is too crucial to the topic to reuse the obvious name FHE to mean something completely different. I have not read the thesis in detail and am not qualified to comment; I am merely bringing attention to this possible confusion. Quondum^talk_contr 05:03, 17 December 2011 (UTC)

A slide from a talk by Nigel Smart and Frederik Vercauteren (linked in the references section) reads "A somewhat homomorphic scheme is one which can evaluate homomorphically all arithmetic circuits from a given set C (e.g. bounded depth)." Mihalog

Private Biometrics - promotional?

I removed the following from the main article:

In May 2018 the first commercial implementation of private biometrics (privatebiometrics.com) was published, by Open Inference Holdings LLC. The vendor used novel machine learning models to generate 4kB private biometric feature vectors and thus allowed similarity both between vectors to be calculated (1:1 verification) and achieved cryptography’s “holy grail” by using the same method to provide 1:many identification in polynomial time across a large biometrics database (100 million faces).

On the client device, privatebiometrics.com transforms each reference biometric (template) into a one-way, fully homomorphic, Euclidean-measurable feature vector using matrix multiplication from the neural network that may then be stored locally or transmitted. The original biometric is deleted immediately after the feature vector is computed or, if the solution is embedded in firmware, the biometric is transient and never stored. Once the biometric is deleted, it is no longer possible to lose or compromise the biometric.

It appears to have been added entirely by a single editor who has only added material related to this company. - TheDaveRoss (talk) 17:21, 2 November 2018 (UTC)

And now a seemingly related user has re-added the material. - TheDaveRoss (talk) 03:17, 3 November 2018 (UTC)

--31.154.81.33 (talk) 20:12, 23 November 2018 (UTC) I checked and you are quite right about this seeming promotional. Their website contains reference to a paper they wrote, and claims they created a one-way encryption which supports a measure of distance. Even at the level of basic definitions, this would not qualify as a fully homomorphic cryptosystem. Rather it is much more like this more modest article: a method to measure distance between two faces or voices. Just to complete the picture, their website claims "we first created a list of what not to try. This list detailed all prior approaches to the problem". Enough said.

References

Improving applications

Currently the Applications section is limited to two applications: Encrypted database querying and Bitcoin split-key vanity mining. I suggest removing these two applications entirely and replacing them with newer more realistic, useful, and practical applications for the following reasons:

• For Bitcoin split-key vanity mining, no references are given in the article. Lack of references highlights the fact that this is not considered to be an important application of homomorphic encryption and should probably not be on the Wikipedia page at all.
• For Encrypted database querying, a non-peer reviewed paper is cited that does not at all reflect the current state of homomorphic encryption: "For e.g. a 16 bit multiplication takes approximately 24 minutes." is blatantly false/misleading; such a computation would take milliseconds to perform with modern libraries. While encrypted database querying can be an application, the current paragraph is a non-starter for an informed and modern description of the situation.

I suggest replacing these applications with applications that can all be supported by news articles and/or current peer-reviewed papers, such as:

• (High-level) Applications in cloud storage and computation;
• Applications in machine learning privacy;
• Applications in privacy-preserving statistical computations;
• Applications in genome/biomedical privacy;
• Applications in location privacy;
• Applications in private set intersection/private data retrieval/private database querying.

A separate Issues/Challenges/Critique section should make it very clear what the limitations and costs of homomorphic encryption are and the Applications section should explain how and why the described applications are affected by these costs.

--Kim Laine (talk) 19:37, 13 February 2019 (UTC)

Defining Generations

I notice that the article attempts to create a theme of "generations" for schemes, which leaves the reader with the assumption that older or previous generations are inferior, and then continues on to list CKKS and TFHE (which are both modern and used in modern libraries) as different generations.

Does anyone know why this is and what purpose it serves having these "generations" at all? What is the criteria to define it? Trumbledrip (talk) 01:49, 25 January 2024 (UTC)

Related Research

This section in the original seems like two people fighting with each other about tangentially related research and credit - I recommend cutting it entirely. ItsDrewMiller (talk) 23:18, 11 March 2024 (UTC)

The somewhat homomorphic component in the work of Van Dijk et al. is similar to an encryption scheme proposed by Levieil and Naccache in 2008,[13] and also to one that was proposed by Bram Cohen in 1998.[14] Cohen's method is not even additively homomorphic, however. The Levieil–Naccache scheme supports only additions, but it can be modified to also support a small number of multiplications. Many refinements and optimizations of the scheme of Van Dijk et al. were proposed in a sequence of works by Jean-Sébastien Coron, Tancrède Lepoint, Avradip Mandal, David Naccache, and Mehdi Tibouchi.[15][16][17][18] Some of these works included also implementations of the resulting schemes.

Differences from Blinding (cryptography)

I don't have much experience in this field. At least to me, Blinding (cryptography) seems to be about the very same topic, just with a different name. The article about blinding is even 2 years older than this one about homomorphic encryption. I think it would be helpful, if someone with more insight could link both articles and clarify their relation. See also discussion on the other article. --217.240.200.253 (talk) 17:48, 7 April 2024 (UTC)