Multiparty Secure Computation II: Construction using Fully Homomorphic Encryption, Lecture notes of Mathematics

The use of fully homomorphic encryption to achieve security in the honest-but-curious setting of two-party multiparty secure computation. It presents a protocol for Alice and Bob to run on inputs x, y respectively so that Alice will learn F(x, y) but nothing more about y, and Bob will learn nothing about x that he didn’t know before. The document also defines statistical circuit privacy and its importance in achieving secure computation. suitable for advanced cryptography students.

Typology: Lecture notes

2020/2021

Available from 07/13/2023

tandhi-wahyono
tandhi-wahyono 🇮🇩

5

(15)

774 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1This is by no means the only way to get multiparty
secure computation. In fact, multiparty secure com-
putation was known well before FHE was discovered.
One common construction for achieving this uses a
technique known as Yao’s Garbled Circuit.
17
Multiparty secure computation II: Construction using Fully
Homomorphic Encryption
In the last lecture we saw the definition of secure multiparty com-
putation, as well as the compiler reducing the task of achieving se-
curity in the general (malicious) setting to the passive (honest-but-
curious) setting. In this lecture we will see how using fully homo-
morphic encryption we can achieve security in the honest-but-curious
setting.1We focus on the two party case, and so prove the following
theorem:
Theorem 17.1 Two party honest-but-curious MPC. Assuming the LWE
conjecture, for every two party functionality 𝐹there is a protocol
computing 𝐹in the honest but curious model.
Before proving the theorem it might be worthwhile to recall what
is actually the definition of secure multiparty computation, when
specialized for the 𝑘 = 2and honest but curious case. The defini-
tion significantly simplifies here since we don’t have to deal with the
possibility of aborts.
Definition 17.2 Two party honest-but-curious secure computation. Let 𝐹be
(possibly probabilistic) map of {0,1}𝑛×{0,1}𝑛to {0,1}𝑛×{0,1}𝑛.
Asecure protocol for 𝐹is a two party protocol such for every party
𝑡 {1,2}, there exists an efficient “ideal adversary” (i.e., efficient
interactive algorithm) 𝑆such that for every pair of inputs (𝑥1,𝑥2)
the following two distributions are computationally indistinguish-
able:
The tuple (𝑦1,𝑦2,𝑣)obtained by running the protocol on inputs
𝑥1,𝑥2, and letting 𝑦1,𝑦2be the outputs of the two parties and
𝑣be the view (all internal randomness, inputs, and messages
received) of party 𝑡.
Compiled on 11.17.2021 22:35
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Multiparty Secure Computation II: Construction using Fully Homomorphic Encryption and more Lecture notes Mathematics in PDF only on Docsity!

(^1) This is by no means the only way to get multiparty secure computation. In fact, multiparty secure com- putation was known well before FHE was discovered. One common construction for achieving this uses a technique known as Yao’s Garbled Circuit.

Multiparty secure computation II: Construction using Fully

Homomorphic Encryption

In the last lecture we saw the definition of secure multiparty com- putation, as well as the compiler reducing the task of achieving se- curity in the general (malicious) setting to the passive (honest-but- curious) setting. In this lecture we will see how using fully homo- morphic encryption we can achieve security in the honest-but-curious setting.^1 We focus on the two party case, and so prove the following theorem:

Theorem 17.1 — Two party honest-but-curious MPC. Assuming the LWE conjecture, for every two party functionality 𝐹 there is a protocol computing 𝐹 in the honest but curious model.

Before proving the theorem it might be worthwhile to recall what is actually the definition of secure multiparty computation, when specialized for the 𝑘 = 2 and honest but curious case. The defini- tion significantly simplifies here since we don’t have to deal with the possibility of aborts.

Definition 17.2 — Two party honest-but-curious secure computation. Let 𝐹 be (possibly probabilistic) map of {0, 1}𝑛^ × {0, 1}𝑛^ to {0, 1}𝑛^ × {0, 1}𝑛. A secure protocol for 𝐹 is a two party protocol such for every party 𝑡 ∈ {1, 2}, there exists an efficient “ideal adversary” (i.e., efficient interactive algorithm) 𝑆 such that for every pair of inputs (𝑥 1 , 𝑥 2 ) the following two distributions are computationally indistinguish- able:

  • The tuple (𝑦 1 , 𝑦 2 , 𝑣) obtained by running the protocol on inputs 𝑥 1 , 𝑥 2 , and letting 𝑦 1 , 𝑦 2 be the outputs of the two parties and 𝑣 be the view (all internal randomness, inputs, and messages received) of party 𝑡.

Compiled on 11.17.2021 22:

336 an intensive introduction to cryptography

Figure 17.1 : An honest but curious protocol for two party computation using a fully homomorphic encryption scheme with circuit privacy.

  • The tuple (𝑦 1 , 𝑦 2 , 𝑣) that is computed by letting (𝑦 1 , 𝑦 2 ) = 𝐹 (𝑥 1 , 𝑥 2 ) and 𝑣 = 𝑆(𝑥𝑡, 𝑦𝑡).

That is, 𝑆, which only gets the input 𝑥𝑡 and output 𝑦𝑡, can sim- ulate all the information that an honest-but-curious adversary controlling party 𝑡 will view.

17.1 CONSTRUCTING 2 PARTY HONEST BUT CURIOUS COMPUTA- TION FROM FULLY HOMOMORPHIC ENCRYPTION

Let 𝐹 be a two party functionality. Lets start with the case that 𝐹 is de- terministic and that only Alice receives an output. We’ll later show an easy reduction from the general case to this one. Here is a suggested protocol for Alice and Bob to run on inputs 𝑥, 𝑦 respectively so that Alice will learn 𝐹 (𝑥, 𝑦) but nothing more about 𝑦, and Bob will learn nothing about 𝑥 that he didn’t know before.

Protocol 2PC: (See Fig. 17.1)

  • Assumptions: (𝐺, 𝐸, 𝐷, EVAL ) is a fully homo- morphic encryption scheme.
  • Inputs: Alice’s input is 𝑥 ∈ {0, 1}𝑛^ and Bob’s in- put is 𝑦 ∈ {0, 1}𝑛. The goal is for Alice to learn only 𝐹 (𝑥, 𝑦) and Bob to learn nothing.
  • Alice->Bob: Alice generates (𝑒, 𝑑) ←𝑅 𝐺(1𝑛) and sends 𝑒 and 𝑐 = 𝐸𝑒(𝑥).
  • Bob->Alice: Bob defines 𝑓 to be the function 𝑓(𝑥) = 𝐹 (𝑥, 𝑦) and sends 𝑐′^ = EVAL (𝑓, 𝑐) to Alice.
  • Alice’s output: Alice computes 𝑧 = 𝐷𝑑(𝑐′).

First, note that if Alice and Bob both follow the protocol, then in- deed at the end of the protocol Alice will compute 𝐹 (𝑥, 𝑦). We now claim that Bob does not learn anything about Alice’s input:

Claim B: For every 𝑥, 𝑦, there exists a standalone algorithm 𝑆 such that 𝑆(𝑦) is indistinguishable from Bob’s view when interacting with Alice and their corresponding inputs are (𝑥, 𝑦).

Proof: Bob only receives a single message in this protocol of the form (𝑒, 𝑐) where 𝑒 is a public key and 𝑐 = 𝐸𝑒(𝑥). The simulator 𝑆 will generate (𝑒, 𝑑) ←𝑅 𝐺(1𝑛) and compute (𝑒, 𝑐) where 𝑐 = 𝐸𝑒(0𝑛). (As usual 0 𝑛^ denotes the length 𝑛 string consisting of all zeroes.) No matter what 𝑥 is, the output of 𝑆 is indistinguishable from the message Bob receives by the security of the encryption scheme. QED

338 an intensive introduction to cryptography

(^2) It’s true that strictly speaking, we allowed EVAL ’s output to have length at most 𝑛, while this would make the output be 𝑛 + 100, but this is just a tech- nicality that can be easily bypassed, for example by having a new scheme that on security parameter 𝑛 runs the original scheme with parameter 𝑛/2 (and hence will have a lot of “room” to pad the output of EVAL with extra bits).

So, it turns out that Claim A is not generically true. The reason is the following: the definition of fully homomorphic encryption only re- quires that EVAL (𝑓, 𝐸(𝑥)) decrypts to 𝑓(𝑥) but it does not require that it hides the contents of 𝑓. For example, for every FHE, if we modify EVAL (𝑓, 𝑐) to append to the ciphertext the first 100 bits of the descrip- tion of 𝑓 (and have the decryption algorithm ignore this extra infor- mation) then this would still be a secure FHE.^2 Now we didn’t exactly specify how we describe the function 𝑓(𝑥) defined as 𝑥 ↦ 𝐹 (𝑥, 𝑦) but there are clearly representations in which the first 100 bits of the description would reveal the first few bits of the hardwired constant 𝑦, hence meaning that Alice will learn those bits from Bob’s message. Thus we need to get a stronger property, known as circuit privacy. This is a property that’s useful in other contexts where we use FHE. Let us now define it: ::: {.definition title=“Perfect circuit privacy” #perfectcircprivat- edef} Let ℰ = (𝐺, 𝐸, 𝐷, EVAL ) be an FHE. We say that ℰ satisfies perfect circuit privacy if for every (𝑒, 𝑑) output by 𝐺(1𝑛) and every function 𝑓 ∶ {0, 1}ℓ^ → {0, 1} of 𝑝𝑜𝑙𝑦(𝑛) description size, and ev- ery ciphertexts 𝑐 1 , … , 𝑐ℓ and 𝑥 1 , … , 𝑥ℓ ∈ {0, 1} such that 𝑐𝑖 is output by 𝐸𝑒(𝑥𝑖), the distribution of EVAL 𝑒(𝑓, 𝑐 1 , … , 𝑐ℓ) is identical to the distribution of 𝐸𝑒(𝑓(𝑥)). That is, for every 𝑧 ∈ {0, 1}∗, the probabil- ity that EVAL 𝑒(𝑓, 𝑐 1 , … , 𝑐ℓ) = 𝑧 is the same as the probability that 𝐸𝑒(𝑓(𝑥)) = 𝑧. We stress that these probabilities are taken only over the coins of the algorithms EVAL and 𝐸. Perfect circuit privacy is a strong property, that also automatically implies that 𝐷𝑑( EVAL (𝑓, 𝐸𝑒(𝑥 1 ), … , 𝐸𝑒(𝑥ℓ))) = 𝑓(𝑥) (can you see why?). In particular, once you understand the definition, the follow- ing lemma is a fairly straightforward exercise.

Lemma 17.3 If (𝐺, 𝐸, 𝐷, EVAL ) satisfies perfect circuit privacy then if (𝑒, 𝑑) = 𝐺(1𝑛) then for every two functions 𝑓, 𝑓′^ ∶ {0, 1}ℓ^ → {0, 1} of 𝑝𝑜𝑙𝑦(𝑛) description size and every 𝑥 ∈ {0, 1}ℓ^ such that 𝑓(𝑥) = 𝑓′(𝑥), and every algorithm 𝐴,

| Pr[𝐴(𝑑, EVAL (𝑓, 𝐸𝑒(𝑥 1 ), … , 𝐸𝑒(𝑥ℓ))) = 1]−Pr[𝐴(𝑑, EVAL (𝑓′, 𝐸𝑒(𝑥 1 ), … , 𝐸𝑒(𝑥ℓ))) = 1]| < 𝑛𝑒𝑔𝑙(𝑛). (17.1)

P Please stop here and try to prove Lemma 17.

The algorithm 𝐴 above gets the secret key as input, but still cannot distinguish whether the EVAL algorithm used 𝑓 or 𝑓′. In fact, the expression on the lefthand side of (17.1) is equal to zero when the scheme satisfies perfect circuit privacy.

multiparty secure computation ii: construction using fully homomorphic encryption 339

However, for our applications bounding it by a negligible function is enough. Hence, we can use the relaxed notion of “imperfect” circuit privacy, defined as follows:

Definition 17.4 — Statistical circuit privacy. Let ℰ = (𝐺, 𝐸, 𝐷, EVAL ) be an FHE. We say that ℰ satisfies statistical circuit privacy if for every (𝑒, 𝑑) output by 𝐺(1𝑛) and every function 𝑓 ∶ {0, 1}ℓ^ → {0, 1} of 𝑝𝑜𝑙𝑦(𝑛) description size, and every ciphertexts 𝑐 1 , … , 𝑐ℓ and 𝑥 1 , … , 𝑥ℓ ∈ {0, 1} such that 𝑐𝑖 is output by 𝐸𝑒(𝑥𝑖), the distribution of EVAL 𝑒(𝑓, 𝑐 1 , … , 𝑐ℓ) is equal up to 𝑛𝑒𝑔𝑙(𝑛) total variation distance to the distribution of 𝐸𝑒(𝑓(𝑥)). That is,

∑ 𝑧∈{0,1}∗

|Pr[ EVAL 𝑒(𝑓, 𝑐 1 , … , 𝑐ℓ) = 𝑧] − Pr[𝐸𝑒(𝑓(𝑥)) = 𝑧]| < 𝑛𝑒𝑔𝑙(𝑛)

where once again, these probabilities are taken only over the coins of the algorithms EVAL and 𝐸.

If you find Definition 17.4 hard to parse, the most important points you need to remember about it are the following:

  • Statistical circuit privacy is as good as perfect circuit privacy for all applications, and so you can imagine the latter notion when using it.
  • Statistical circuit privacy can easier to achieve in constructions.

(The third point, which goes without saying, is that you can always ask clarifying questions in class, Piazza, sections, or office hours…) Intuitively, circuit privacy corresponds to what we need in the above protocol to protect Bob’s security and ensure that Alice doesn’t get any information about his input that she shouldn’t have from the output of EVAL , but before working this out, let us see how we can construct fully homomorphic encryption schemes satisfying this property.

17.2 ACHIEVING CIRCUIT PRIVACY IN A FULLY HOMOMORPHIC ENCRYPTION

We now discuss how we can modify our fully homomorphic encryp- tion schemes to achieve the notion of circuit privacy. In the scheme we saw, the encryption of a bit 𝑏, whether obtained through the en- cryption algorithm or EVAL , always had the form of a matrix 𝐶 over ℤ𝑞 (for 𝑞 = 2

√𝑛 ) where 𝐶𝑣 = 𝑏𝑣 + 𝑒 for some vector 𝑒 that is “small” (e.g., for every 𝑖, |𝑒𝑖| < 𝑛𝑝𝑜𝑙𝑦𝑙𝑜𝑔(𝑛)^ ≪ 𝑞 = 2

√𝑛 ). However, the EVAL algorithm was deterministic and hence this vector 𝑒 is a function of

multiparty secure computation ii: construction using fully homomorphic encryption 341

if |𝑎|, |𝑏| ≤ 𝛿𝑇 then the symmetric difference is roughly a 2𝛿 fraction of the union.

We will not provide the full details, but together these lemmas show that EVAL can use bootstrapping to reduce the magnitude of the noise to roughly 2 𝑛0.1 and then add an additional random noise of roughly, say, 2 𝑛0.2 which would make it statistically indistinguishable from the actual encryption. Here are some hints on how to make this work: the idea is that in order to “re-randomize” a ciphertext 𝐶 we need a very noisy encryption of zero and add it to 𝐶. The normal encryption will use noise of magnitude 2 𝑛0.2 but we will provide an encryption of the secret key with smaller magnitude 2 𝑛0.1/𝑝𝑜𝑙𝑦𝑙𝑜𝑔(𝑛) so we can use bootstrapping to reduce the noise. The main idea that allows to add noise is that at the end of the day, our scheme boils down to LWE instances that have the form (𝑐, 𝜎) where 𝑐 is a random vector in ℤ𝑛−1𝑞 and 𝜎 = ⟨𝑐, 𝑠⟩ + 𝑎 where 𝑎 ∈ [−𝜂, +𝜂] is a small noise addition. If we take any such input and add to 𝜎 some 𝑎′^ ∈ [−𝜂′, +𝜂′] then we create the effect of completely re-randomizing the noise. However, completely analyzing this requires non-trivial amount of care and work.

17.2.1 Bottom line: A two party secure computation protocol Using the above we can obtain the following theorem:

Theorem 17.7 — Re-randomizable FHE. If the LWE conjecture is true then there exists a tuple of polynomial-time randomized algorithms (𝐺, 𝐸, 𝐷, EVAL , RERAND ) such that:

  • (𝐺, 𝐸, 𝐷, EVAL ) is a CPA secure fully-homomorphic encryption for one bit messages. That is, if (𝑑, 𝑒) = 𝐺(1𝑛) then for every Boolean circuit 𝐶 with ℓ inputs and one output, and 𝑥 ∈ {0, 1}ℓ, the ciphertext 𝑐 = EVAL 𝑒(𝐶, 𝐸𝑒(𝑥 1 ), … , 𝐸𝑒(𝑥ℓ) has length 𝑛 and 𝐷𝑑(𝑐) = 𝐶(𝑥) with probability one over the random choices of the algorithms 𝐸 and EVAL.
  • For every pair of keys (𝑒, 𝑑) = 𝐺(1𝑛) there are two distributions 𝒞^0 , 𝒞^1 over {0, 1}𝑛^ such that: - For 𝑏 ∈ {0, 1}, Pr𝑐∼𝒞𝑏 [𝐷𝑑(𝑐) = 𝑏] = 1. That is, 𝒞𝑏^ is distributed over ciphertexts that decrypt to 𝑏. - For every ciphertext 𝑐 ∈ {0, 1}𝑛^ in the image of either 𝐸𝑒(⋅) or EVAL 𝑒(⋅), if 𝐷𝑑(𝑐) = 𝑏 then RERAND 𝑒(𝑐) is statistically indistinguishable from 𝒞𝑏. That is, the output of RERAND 𝑒(𝑐)

342 an intensive introduction to cryptography

(^3) I believe this notation originates with Burrows– Abadi–Needham (BAN) logic though would be happy to get corrections/references.

is a ciphertext that decrypts to the same plaintext as 𝑐, but whose distribution is essentially independent of 𝑐.

Proof Idea: We do not include the full proof but the idea is we use our standard LWE-based FHE and to rerandomize a ciphertext 𝑐 we will add to it an encryption of 0 (which will not change the corresponding plaintext) and an additional noise vector that would be of much larger mag- nitude than the original noise vector of 𝑐, but still small enough so decryption succeeds. ⋆

Using the above re-randomizable encryption scheme, we can re- define EVAL to add a RERAND step at the end and achieve statistical circuit privacy. If we use Protocol 2PC with such a scheme then we get a two party computation protocol secure with respect to honest but curious adversaries. Using the compiler of Theorem 16.5 we obtain a proof of Theorem 16.3 for the two party setting:

Theorem 17.8 — Two party secure computation. If the LWE conjecture is true then for every (potentially randomized) functionality 𝐹 ∶ {0, 1}𝑛^1 × {0, 1}𝑛^2 → {0, 1}𝑚^1 × {0, 1}𝑚^2 there exists a polynomial-time protocol for computing the functionality 𝐹 secure with respect to potentially malicious adversaries.

17.3 BEYOND TWO PARTIES

We now sketch how to go beyond two parties. It turns out that the compiler of honest-but-curious to malicious security works just as well in the many party setting, and so the crux of the matter is to obtain an honest but curious secure protocol for 𝑘 > 2 parties. We start with the case of three parties - Alice, Bob, and Charlie. First, let us introduce some convenient notation (which is used in other settings as well).^3 We will assume that each party initially gen- erates private/public key pairs with respect to some fully homomor- phic encryption (satisfying statistical circuit privacy) and sends them to the other parties. We will use {𝑥}𝐴 to denote the encryption of 𝑥 ∈ {0, 1}ℓ^ using Alice’s public key (similarly {𝑥}𝐵 and {𝑥}𝐶 will denote the encryptions of 𝑥 with respect to Bob’s and Charlie’s pub- lic key. We can also compose these and so denote by {{𝑥}𝐴}𝐵 the encryption under Bob’s key of the encryption under Alice’s key of 𝑥. With the notation above, Protocol 2PC can be described as follows:

Protocol 2PC: (Using BAN notation)

344 an intensive introduction to cryptography

functionality (𝑥, 𝑦, 𝑧) ↦ (𝐹 (𝑥, 𝑦, 𝑧), ⊥, ⊥) with respect to honest- but-curious adversaries.

Proof. Left to the reader :) ■