- Functional Encryption: Definitions and Challenges
- Multi-Input Functional Encryption
- Ad Hoc Multi-Input Functional Encryption
In this paper, authors proved two main results:
- aMIFE for general functionality can be constructed by standard MIFE + general FE + function re-runnable two-round MPC.
- As a special case, aMIFE for the inner product functionality can be constructed from standard assumption: Learning From Error (LWE)
To figure out how it is achieved, we need to start from the building blocks:
Functional Encryption (FE):
Consider a cloud image storage service. Law enforcement may require the cloud to search for images containing a particular face. For protecting users’ privacy (if there is still any), the cloud needs a restricted secret key that only decrypts a target image, and only decrypts the target face in clear, while still keeps all other parts of the images blurred. In this scenario, the secret key only reveals a function of the plaintext image. We know traditional public key cryptography is an “all or nothing” scheme, which means either we can decrypt and read the entire plaintext, or we are not able to decrypt it and thus learn nothing about the plaintext. So here function encryption (FE) comes to rescue. Just as in traditional encryption, in FE, ciphertexts can be generated with an encryption key. However, each decryption key is associated with a function , and decryption of an encryption of using this key results in not but . Informally, the security definition of FE requires nothing more than can be learned from the encryption of and the decryption key for .
Multi-Input Functional Encryption (MIFE):
Note that FE only works for computing a function on a single ciphertext. Moving one step further, what if we want to compute a function defined over multiple plaintexts given their ciphertexts each encrypted under a different key? Now we need to introduce MIFE. In MIFE, decryption keys allow computing joint functions of different plaintexts underlying multiple ciphertexts. That is, decryption takes a key for a function and ciphertexts encrypting , and outputs . The interactive pattern of MIFE can be summarized into the following steps:
- Suppose there are users involved. This number is counted and sent to a trusted global setup. The global setup outputs a master secret key , and a set of encryption keys , one for each user.
- The global setup picks a function , and generates a decryption key using and . The subscript indicates this decryption key is associated with .
- The global setup publishes the public parameters to all users, and distributes each encryption key to user with index . Note that this step can be done in parallel with step 2.
- Each user encrypts their plaintext upon receiving encryption key to get a ciphertext .
- All users send their ciphertexts to the aggregator, who now computes the result using the decryption key .
The motivation of aMIFE comes from these two drawbacks of the standard MIFE presented above:
- In MIFE, encryption and decryption keys are generated via a global setup procedure run by an external entity, called the “key authority”. This key authority is able to decrypt all the ciphertexts gathered from users. It also picks which function to be computed. Therefore, it must be trusted to maintain the security of this scheme.
- In MIFE, the number of function arity must be declared at setup time. It does not support a dynamic setting in which users can join or leave.
Where is challenging part to improve these two drawbacks?
For eliminating the key authority, a natural idea is to use MPC to replace it. However, naively using MPC as setup would introduce interaction between users, which MIFE doesn’t allow. Hence we can try Two-round MPC.
Here is how it works:
- Round One: Assume the number of users and the function to be computed of arity is predetermined. Each user feeds their index and plaintext into the first round MPC, and get the first round message and a secret .
- Round Two: All users publish their first round message . Using all these first round messages, together with each secret , each user computes the second round message
- Compute Result: All users send their second round messages to an aggregator, and the aggregator computes the final result .
However, naively using a two-round MPC does not suffice, as it introduces two issues:
- This template publishes fresh public parameters for each , but MIFE requires publishing only once.
- is not known given just the first round MPC messages, so users are not able to encrypt.
Solution to 1: Function re-runnable two-round MPC:
We require that the first round MPC message to be sent only once, and reused for all subsequent second round messages. This property is called “function re-runnable”. Moreover, we require the number of users to be declared during the second round of MPC, instead of at the time that the first round is sent. This property is called “function delayed”.
Solution to 2: Delaying Encryption:
We allow the users to delay encryption until are known. During the setup, each user runs a FE scheme to get the FE master key. This master key is used to compute the first round MPC message. Additionally, each user encrypts their input using FE.Encrypt.
aMIFE Interaction Pattern:
We want to let each user run a local setup, which replaces the trusted global setup in standard MIFE. In addition, we want the number of users to be undetermined in the setup procedure, so that it allows users to join or leave in the computation process. For simplicity, we present the aMIFE in the private-key setting:
- Each user runs a local setup to generate some public parameters and a private encryption key .
- Each user publishes their public parameters, and encrypts their input using the private encryption key only, nothing else.
- Using their private encryption keys, users can issue partial decryption keys to the aggregator. Each partial decryption key is generated by the public parameters of other users.
- If these other users also issue the matching partial encryption keys for to the aggregator, then the aggregator can decrypt the ciphertexts using all partial decryption keys . The final result is
But how to replace the global setup using local setup? The idea is to nest FE, MIFE and Two Round MPC together.
aMIFE for General Functionalities:
Now we are ready to present the complete aMIFE scheme for general functionalities:
- Local Setup: Each user runs FE scheme to generate a FE master secret key . Feed this into the first round MPC to get the first round protocol message and a secret . Set public parameter and master secret key . Note that the global setup in standard MIFE is bypassed using FE and first round MPC.
- Key Generation: Suppose users are chosen to participate in the computation, then these users publish their public parameters and master secret keys. Each user runs second round MPC to generated a second round message , which is the partial decryption key .
“Ad hoc Friendliness”:
We say a MIFE scheme is “ad hoc friendly” if it satisfies the following three conditions:
- Decentralized Setup: The encryption keys and the partial master secret key for each user can be generated locally.
- Local Encryption: Each user is able to encrypt using their encryption key $EK_i$ and plaintext , nothing else. The encryption process is fully independent from the number of users .
- Piecewise Master Secret Key: If we restrict the master secret key to some subset S with , the subset has the same distribution as a master secret key generated for functions of arity .