Rishabh Poddar
What is the main insight/technique in Gentry's work on FHE that keeps the noise low, and prevents the noise from affecting the correctness of the computation result when decrypted?
A somewhat homomorphic encryption (SHE) scheme can only perform a limited number of homomorphic computations before the noise becomes large enough to render the scheme useless (i.e. it does no decrypt correctly). However, if an SHE can evaluate its own decryption homomorphically, then it can be used to build a fully homomorphic encryption (FHE) scheme. This can be done by encrypting the noisy ciphertext along with the secret key, and then using the SHE to decrypt the cipher text homomorphically. The result will be a new encryption of the message, but without the original noise (which would have been removed because of the decryption). The homomorphic decryption will simultaneously introduce new noise, but as long as this addition is less than the noise that was removed, the net noise remains bounded.
Describe the difference between functional encryption and fully homomorphic encryption.
Both functional encryption (FE) and fully homomorphic encryption (FHE) are public key schemes. However, in FE, there are multiple other keys generated from the master secret key, with each key being tied to a particular function. Anyone who has one of these keys (tied to some function), can decrypt the cipher text to obtain the function’s result over the plaintext. The security of FE therefore requires that the server learns nothing about the plaintext x, other than the computation result f(x).
This is a weaker security guarantee than FHE where the computed result remains encrypted, and the server learns nothing. FHE thus provides semantic security.
Assuming both of these schemes were efficient (which they are far from being) while supporting general functions, and function evaluation costs the same in both, discuss which one would you deem more fit for computing SQL queries on an encrypted database and why?
Functional encryption is more suited to evaluating SQL queries on an encrypted database. This is because the security guarantees of FHE make it inherently impractical even if the scheme is made efficient. The database would no longer be allowed to use indexes, and would need to do a full scan for every query. This is because FHE prevents the server from learning anything about the data, even learning whether some data satisfies the query or not. By excluding items from its computation, the server would learn that those values did not match the query, which is not allowed. This would be prohibitively slow. Moreover, the server cannot even learn how many rows the result contains. Thus, it would always return the worst-case number of rows every time, which would be severely impractical.
On the other hand, SQL queries can be efficiently computed with functional encryption (assuming the scheme itself is efficient). For example, the client could give the server keys for functions that enable the server to navigate the database index. This would eliminate the need for expensive, full sequential scans. Another key could potentially allow the server to evaluate whether or not a particular row satisfies a query, and the server would not need to return the whole database. Clearly, this comes at the cost of security guarantees, as now the server knows whether a row matches a query or not. However, it learns nothing about the content of the rows.
Rohan Padhye
1) What is the main insight/technique in Gentry's work on FHE that
keeps the noise low, and prevents the noise from affecting the correctness of
the computation result when decrypted?
Instead of merely evaluating a function on a set of encrypted ciphertexts that will increase the noise in the result, Gentry's scheme evaluates a composition of the decryption function and the actual operation to perform on an auxiliary ciphertext which is doubly encrypted, first with the main public key and then with a secret key that's encrypted with the initial ciphertext. Due to the evaluation of the decryption function, the number of bits of noise is kept to a minimum.
2) Describe the difference between functional encryption and fully
homomorphic encryption.
In functional encryption, the entity that computes the function f(x) over an encrypted representation of x learns the value of f(x), while in fully homomorphic encryption it does not (i.e. an encrypted representation of f(x) is returned).
For example, if f(x) is a search for a keyword, the entity that performs the computation on the encrypted text might learn whether or not f(x) returned true for a particular text input, but it is possible to not reveal the function 'f' itself, and hence the entity would not know what keyword was contained in the input text 'x' (or in fact that the operation was a keyword search).
3) Assuming both of these schemes were efficient (which they are far
from being) while supporting general functions, and function
evaluation costs the same in both, discuss which one would you deem more fit
for computing SQL queries on an encrypted database and why?
Functional encryption is more useful in the context of databases since it allows the database server to optimize queries by performing them on a subset of the data, or returning only a subset of the entire data when the query result is small. In FHE, the server cannot learn that some part of the data is not relevant for a particular operation, since that is deemed as leaking information - and hence this forces every operation to take at least time linear to the size of the stored data.
Katia Patkin
1) What is the main insight/technique in Gentry's work on FHE that keeps the noise low, and prevents the noise from affecting the correctness of the computation result when decrypted?
The construction starts from a somewhat homomorphic encryption scheme, which is limited to evaluating low-degree polynomials over encrypted data. (It is limited because each ciphertext is noisy in some sense, and this noise grows as one adds and multiplies ciphertexts, until ultimately the noise makes the resulting ciphertext indecipherable.) Gentry then shows how to slightly modify this scheme to make it bootstrappable,i.e., capable of evaluating its own decryption circuit and then at least one more operation. Finally, he shows that any bootstrappable somewhat homomorphic encryption scheme can be converted into a fully homomorphic encryption through a recursive self-embedding. For Gentry's "noisy" scheme, the bootstrapping procedure effectively "refreshes" the ciphertext by applying to it the decryption procedure homomorphically, thereby obtaining a new ciphertext that encrypts the same value as before but has lower noise. By "refreshing" the ciphertext periodically whenever the noise grows too large, it is possible to compute arbitrary number of additions and multiplications without increasing the noise too much.
2) Describe the difference between functional encryption and fully homomorphic encryption.
Fully homomorphic encryption is a public-key encryption scheme. The evaluation of any function is done over the encrypted data. A function f to be evaluated is typically represented as a boolean circuit of polynomial size in the input size. The current FHE schemes enable running virtually any function over encrypted data. FHE provides strong security guarantees, called semantic security, which requires that any adversary holding only the public key and a cipher-text cannot learn any information about the underlying plaintext, other than its length. Nevertheless, FHE is too slow for running arbitrary functions or for enabling the complex systems. There are at least three factors that make FHE slow: the cryptographic overhead, the model of computation, and the strong security definition. The security guarantees, brings about inherent impracticality. Even if its cryptographic overhead were zero, the security guarantee is so strong that it prevents certain needed optimizations.
In functional encryption anyone can encrypt an input x with a master public key. The holder of the master secret key can provide keys for functions. Anyone with access to a secret key for function and the cipher-text can obtain the result of the computation in plaintext form, f(x), by running decryption. The security of FE requires that the adversary learns nothing about x, other than the computation result f(x). Some schemes hide the function f as well. In contrast to the homomorphic encryption, in which the server obtains an encrypted computation result of f(x) and does not know f(x). Hence, this is a weaker security than semantic security; nevertheless, by choosing f in a careful way, one can ensure that little information leaks about x. The practicality of a scheme depends on its cryptographic overhead, model and security. In terms of model and security, FE is closer to practice than FHE. If the cryptographic overhead were engineered to be very small, unlike FHE, the model and security of FE no longer exclude the practical applications.
3) Assuming both of these schemes were efficient (which they are far from being) while supporting general functions, and function evaluation costs the same in both, discuss which one would you deem more fit for computing SQL queries on an encrypted database and why?
In fully homomorphic encryption, the security guarantees, brings about inherent impracticality, even if the cryptographic overhead is practically zero, the security guarantee is so strong that it prevents certain needed optimizations. On the other hand, in functional evaluation if the cryptographic overhead is very small, the model and security of FE no longer exclude the practical applications. However, FE does not provide semantic security that is it enables the server to learn a function of the data. Still I deem that for computing SQL queries on an encrypted database FE is more fit, because one can instrument the function of the data that the server learns, so the information leakage is small and does not affect privacy, yet provide a significant increase in performance by using the optimized solution for the particular function, what is impossible in FHE due to the very strict security constraints.