1 / 25

Secure Computation in the Preprocessing Model MPC workshop, 2012 Ivan Damgård

Secure Computation in the Preprocessing Model MPC workshop, 2012 Ivan Damgård Dept. Of Computer Science, Århus University. The MPC scenario for this talk. The players. x2, y2. x1, y1. Inputs, Desired outputs. Communication Network. Corrupt. Adv. x3,y3. x4,y4.

irina
Download Presentation

Secure Computation in the Preprocessing Model MPC workshop, 2012 Ivan Damgård

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Secure Computation in the Preprocessing Model MPC workshop, 2012 Ivan Damgård Dept. Of Computer Science, Århus University

  2. The MPC scenario for this talk The players x2, y2 x1, y1 Inputs, Desired outputs Communication Network Corrupt Adv x3,y3 x4,y4 • Secure point-to-point channels. • Synchronous network. • Active corruption.

  3. The Case of Dishonest Majority Assume t=n-1 of the n players can be corrupted. Cannot have information theoretic security. But we can protect against a computationally bounded adversary using public-key technology: If t=n-1, we can compute any function securely, based on suitable computational assumptions (but termination cannot be guaranteed). So information theoretic tools useless here? NO! ”MPC in the head” can improve efficiency [IKOS06, etc.] ”On-line/off-line MPC” (this talk: [Bendlin Damgård Orlandi Zakarias EuroCrypt 11], [Damgård Pastro Smart Zakarias Crypto 12], and [Damgård Zakarias 12])

  4. On-Line/Off-line MPC • Preprocessing Phase, can be done any time, inputs, function to compute need not be known. Create raw material for • On-line phase, inputs supplied here. Function can be computed more efficiently because we have raw material from preprocessing. • Goal: use only cheap information theoretic tools here, push all the expensive public-key stuff into preprocessing. In the following.. Think of the Preprocessing as Trusted Dealer, whom we can ask to give us data in any form we like. Later, must implement the dealer via secure protocol that does not assume trusted parties..

  5. Information Theoretic Message Authentication Codes (MACs) and Secret-Sharing. Basic idea: values occurring in the computation will be secret-shared and we protect against malicious attacks by authenticating the shares using unconditionally secure message authentication codes (MACs). First seen in [RB89], in different form in [BDOZ11] where we also did a preprocessing phase based on so called semi-homomorphic encryption.

  6. An issue with authentication of shares: Each player needs his own key (all other players could be corrupt) -> each share must be authenticated with n MACs -> total storage and communication complexity is O(n2). Doing Better with Many Players and Arithmetic Circuits [joint work with Pastro, Smart and Zakarias, Crypto 2012] Also known as “SPDZ”.. Observation: what we really want to protect is the shared value, not the shares...

  7. An Authentication scheme A security game for the authentication scheme we will use: Message x, Key α, MAC is mx = α x mod p, p a prime x x+e Sender 1 mx+e’ Receiver x α e’ Check: is mx+e’ = α (x +e) mod p ? Adversary wins if wrong value of x is accepted. To win, must guess α. mx Sender 2 mx = α x mod p

  8. The representation of secret values Secret value x= x1+x2 mod p, x1,x2 shares in x MAC mx = α x = m(x)1 + m(x)2 mod p shares in the MAC Dealer keeps the key α, will release it on request. x1 x2 m(x)1 m(x)2 If one of the players is malicious, cannot reconstruct x correctly. Could try to check the MAC, but then we need the key and given the key, anyone can forge new MACs Solution: just open shares of x and hope for the best. Call this a partial opening. Turns out to be OK as long as we do not reveal sensitive info *and* if we catch errors before it is too late.

  9. Representation cnt’d. [x] = (x1, m(x)1 x2, m(x)2) [y] = (y1, m(y)1 y2, m(y)2) Can define [x] +[y] = [x+y] by local component-wise addition. Similar for multiplication by public constants.

  10. Multiplication [Beaver’s Circuit Randomization Technique] Given [x], [y], want to compute [xy] Assume the trusted dealer gives to the players [a], [b], [c], random a,b, c=ab. Partially open e= x-a, d= y-b Then, if values are correct, we have: [xy] = [c] + e[b] + d[a] + ed

  11. Putting it all together – Three Phases Input Phase – make representation [x] for each input value [x] (details skipped here). Computation Phase – work our way through the circuit Addition gates, no communication. Each multiplication gate consumes a multiplication triple, and we (partially)open two random values. Output Phase – open the outputs (to be described).

  12. Many Players • [x] defined to be • x1,…, xn with x= x1+…+xn mod p • m(x)1,…, m(x)n with mx= m(x)1+…+m(x)n mod p and where mx = αx mod p • And Dealer holds α Fits with the security game: adversary must modify message and MAC before seeing MAC and key. Computation and Output phase in more detail: Computation Phase: For every [x] to open, we only open the x-value, not the MAC. Instead people commit to their shares of the MACs. Stop just before we open the outputs, commit to the shares you would reveal to open results. Output Phase: Dealer opens the key α. Players open commitments to shares of MACs. If all OK, we know we are about to reveal correct results, so we complete protocol by also revealing shares/MACs of the output. x x+e Sender1 Receiver mx+e’ x α e’ mx Sender 2 mx = αx mod p

  13. Further Improvement. Now players only store a constant number of field elements per shared value [x]. But need to commit to shares of all macs before revealing them. Too expensive. We have [x1], [x2],…,[xt] and opened values x’1,…, x’t Want to check whether xi= x’i Instead of checking individually, take a random linear combination – choose e1,…,et at random and compute (locally) [y] = [e1 x1 + … + et xt] as well as y’= e1 x’1 +…+ et x’t. Now people commit only to shares in the mac for [y] and we check that y’=y. Can be shown that if any x’i is incorrect, y’ is correct only with probability 1/ size of field.

  14. Summing up For n players, to compute circuit of size S securely with error probability ≈ 1/p, each player needs (essentially): - Storing O(S) field elements. - Do O(S) local field operations. For large fields, where 1/p acceptable error probability, means each player spends not much more work than we need to compute the circuit with no security. For a preprocessing model allowing to compute any circuit of size <= S, can show that storage is optimal and work is optimal up to a polylog factor. Communication is O(S) as well – is this optimal?? Implementation: 3 players, connected on a LAN, 64 bit prime p, one secure multiplication in amortized time 0.05 ms.

  15. Implementing the Dealer, or: Preprocessing Based on a somewhat homomorphic encryption scheme allowing many values to be multiplied in parallel inside one ciphertext. Cryptosystem based on the Ring-LWE assumption and variant of [Brakersky et al.], Crypto 2011. Somewhat homomorphic Cryptosystem: A secure public-key scheme, plaintexts are vectors m= (m1,…,ms) in Zps Epk(a+b) = Epk(a) + Epk(b) Epk(a*b) = Epk(a) Epk(b) where a*b is coordinatewise multiplication Dsk(Epk(x))) = x - if Epk(x) is not “too dirty”, i.e. the result of “too many” operations. In our case: “not too many”= 1 multiplication and many additions. Just what we need for preprocessing: each multiplicative triple can be prepared using the same set of operations, can all be done in parallel.

  16. To make it work, lots of stuff needed • ZK proof that you know what is inside a ciphertext you prepared. • Set-up: one global public key, secret key shared among players. A distributed decryption protocol. • Lots of math to analyze what the optimal – and secure - choices of parameters are.

  17. Results for Preprocessing Number of public-key operations spent to prepare a secure multiplication is O(n2/s) where s is number of fields elements packed in one ciphertext (about 12000 in our implementation). Latest implementation: 3 players connected on a LAN, security similar to 1024 bit RSA, spends 10-13 ms. (amortized time) to prepare for 1 secure 64-bit multiplication for 3 players. But see also results from Marcel Keller’s talk later.. Comparison to Other Implementations [Nielsen et al. 11] does Boolean Circuits based on OT extensions and clever cut and choose techniques to get active security. Can do 200-300 AND gates in the time we need for a 64 bit multiplication. Indicates our approach may be faster for arithmetic in large fields.

  18. Boolean Circuits? The SPDZ protocol works also for Boolean circuits, but we would need to use GF(2k) for the MACs, to get small enough error probability. Means we use a k bit MAC to authenticate one bit – large overhead, protocol not optimal for small fields..

  19. Doing Boolean Circuits with (almost) Constant Overhead [Damgård, Zakarias 2012, work in progress] Idea: try to implement the Boolean circuit by doing only blockwise operations, i.e., b+v = (b1,…,bm) + (v1,…,vm) = (b1 + v1,…,bm + vm) b*v = (b1,…,bm) * (v1,…,vm) = (b1 * v1,…,bm * vm) Hope: authenticating a block should be cheaper than authenticating each bit individually. Result from [DIK10]: can restructure any Boolean circuit so that only block-operations and a small number of permutations of bits inside blocks are needed. Comes at cost a logarithmic blow-up. This talk, for simplicity: ignore the permutations inside blocks

  20. New Authentication scheme.. Is based on a (good) linear error correcting code C Equivalent to many 1-bit MACs in parallel Security game for authentication scheme: Message (a codeword) x, Key α, MAC is mx = α*x x x+e Sender 1 mx+e’ Receiver x α e’ Check: is mx+e’ = α*(x +e) ? AND is x+e a codeword? Adversary wins if wrong value is accepted. mx Note that e must be a codeword. Implies adversary much cheat in many positions to win. “many” = minimum distance of C Sender 2 mx = α*x

  21. A new Authentication Scheme for n-bit blocks Secret value x= x1+x2 mod p, x1,x2 shares in x MAC mx = α*x = m(x)1 + m(x)2 shares in the MAC Dealer keeps the key α, will release it on request. x1 x2 m(x)1 m(x)2 If one of the players is malicious, cannot reconstruct x correctly. Solve as before, just open shares of x, check MACs later.

  22. New Message Authentication Codes cnt’d. [x] = (x1, m(x1) x2, m(x2)) mac(x) + mac(y) = α*x + α*y = α*(x+y) = mac(x+y) Problem! multiplications by constants do not work the same way as before: say we have mac(x) = α*xmult. by e on both sides, get e*mac(x) = α*(e*x) Even if e is a codeword, no guarantee that e*α is a codeword! However.. [y] = (y1, m(y1), y2, m(y2)) Can define [x] +[y] = [x+y] by local componentwise addition.

  23. Solving the Problem using the Schur Transform C*= Schur transform of C Defined as linear span of all words of form x*y where x,y are in C. Can arrange that in the protocol e is always in C, so e*a is in C*. If also C* has large minimum distance, then we’re fine. e*mac(x) = α*(e*x) = mac(e*a) When opening, players checks that e*a is in C* Now, everything works as before, including usage of multiplication triples. We just need a family of codes C such that: C and C* have constant information and error rates Encoding into C is efficient (ideally O(m) or O(m log m) ) C should be over a small field, ideally constant size.

  24. Constructions of Codes Can use Reed-Solomon codes based on GF(2log m), For circuit of size S, storage, communication and computation complexity will be O(polylog(m) n S). Can also use codes from Algebraic Geometry [Cramer et al.] -> Field can be constant size. -> Storage and communication complexity will be O(n S) -> Hope to show that also Computational complexity will be O(n S).

  25. THANKS!

More Related