Outline Multiparty Summary
CPSC 467b: Cryptography and Computer Security
Lecture 25
Michael J. Fischer
Department of Computer Science
Yale University
April 21, 2010
Michael J. Fischer CPSC 467b, Lecture 25 1/48
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Privacy-Preserving Computation: Millionaire's Problem & Homomorphic Encryption, Slides of Cryptography and System Security
A lecture outline from cpsc 467b: cryptography and computer security at yale university, covering privacy-preserving multiparty computation, the millionaire's problem, and homomorphic encryption.
Typology: Slides
2010/2011
1 / 48
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Privacy-Preserving Computation: Millionaire's Problem & Homomorphic Encryption and more Slides Cryptography and System Security in PDF only on Docsity!
Outline Multiparty Summary
CPSC 467b: Cryptography and Computer Security
Lecture 25
Michael J. Fischer
Department of Computer Science Yale University
April 21, 2010
Outline Multiparty Summary
(^1) Privacy-Preserving Multiparty Computation The Millionaire’s Problem A General Security Model Private Circuit Evaluation Homomorphic Encryption
2 Summary of Course Since Midterm
Privacy
We have looked at many protocols whose goal is to keep Alice’s information secret from an adversary, or sometimes even from Bob himself. We now look at protocols (like oblivious transfer) whose goal is to control the release of information about Alice’s secret. Just enough information should be released to carry out the purpose of the protocol but no more. This will become clearer with an example.
The Millionaire’s Problem
Privacy-preserving multiparty computation
The Millionaire’s problem, introduced by Andy Yao in 1982, began the study of privacy-preserving multiparty computation. Another example is vote-counting. Each voter has an input vi ∈ { 0 , 1 } indicating their no/yes vote on an issue. The goal is to collectively compute
vi while maintaining the privacy of the individual vi.
A solution to Yao’s problem
For simplicity,assume that I , J ∈ { 1 , 2 ,... , 10 }. Let N be a security parameter, and assume that Alice has public and private RSA keys (e, n) and (d, n), respectively, where n = ¯pq¯, and |¯p| ≈ |q¯| ≈ N 2. A protocol that intuitively works is shown on the next slide.^1
(^1) Adapted from web page “Solution to the Millionaire’s Problem”.
Verbal description
Alice decrypts the numbers m, m + 1,... , m + 9 to get corresponding Y 1 ,... , Y 10. The number YJ is Bob’s secret x, but Alice doesn’t know which it is since all of the Yi ’s “look” random. She then reduces them all mod a random prime p, resulting in Z 1 ,... , Z 10. Note that ZJ = x mod p and the other Zi ’s look random. Finally, she adds 1 (modp) to each of the numbers Zi for which i is greater than her own wealth I. If she adds 1 to ZJ , this means that J > I ; if not J ≤ I. Bob can tell with is the case from the numbers that Alice sends him in step 2c. Namely, if WJ ≡ x (mod p), this means that 1 was not added, so I ≥ J. Otherwise, I < J.
Detailed description
Alice Bob
- Choose x of length N. Let C = E(e,n)(x). ←−^ m Let m = (C − J + 1) mod n. 2a. Yi = D(d,n)(m+i −1), i ∈ [1, 10]. [Note: YJ = x. ]
The number C = (m + J − 1) mod n is the encryption of Bob’s random secret x. The numbers in M = {m mod n,... , (m + 9) mod n} are “random-looking,” and all are possible ciphertexts. Alice knows that C ∈ M but doesn’t know which element it is. After decryption, she knows that some Yi = x but not which one.
Detailed description (cont.)
Alice Bob
- result ←− result = (WJ ≡ x (mod p)).
Since YJ = x, then YJ ≡ ZJ ≡ x (mod p). Hence, if WJ ≡ x (mod p), then J ≤ I , otherwise J > I.
Privacy
Clearly, all that Alice learns from Bob is a set of random-looking numbers m,... , m + 9, one of which corresponds to Bob’s wealth J, but she has no way of telling which, since any number in Z∗ n is the RSA encryption of some plaintext message. Bob on the other hand receives p and W 1 ,... , W 10 from Alice in step 2. However, he does not know any Zi for i 6 = J since he cannot decrypt the corresponding numbers m + i − 1. He also cannot recover Yi from Wi because of the information loss implicit in the “mod p” operation. Thus, he also learns nothing about Alice’s wealth I except for the value of the predicate I ≥ J. We remark that this protocol works only in the semi-honest model in which both Alice and Bob follow their protocol, but both will try to infer whatever they can about the others secrets after the fact.
How can we define multiparty security?
How to define security in a multiparty protocol is far from obvious. For example, in the millionaire’s problem, there is no way to prevent either Alice or Bob from lying about their wealth, nor is it possible to prevent either of them from voluntarily giving up secrecy by broadcasting their wealth. Thus, we can’t hope to find a protocol that will prevent all kinds of cheating.
Ideal versus real protocol security model
What we do instead is to compare a given “real” protocol with a corresponding very simple “ideal” protocol involving a trusted third party. The real protocol should simulate the ideal protocol, much the same as the simulator of a zero knowledge proof system simulates the real interaction between prover and verifier. The real protocol is deemed to be secure if any bad things that can happen in the real protocol are also possible in the ideal protocol.
What does an ideal protocol compute?
What does an ideal multiparty protocol compute? Suppose there are m parties to the protocol, P 1 ,... , Pm. Each Pi has a private input xi and receives a private output yi. We say that F is a (multiparty) functionality if F is a random process that maps m inputs to m outputs. As a special case, we say that F is deterministic if the m outputs are uniquely determined by the m inputs. The millionaire’s problem can be expressed succinctly as the problem of securely computing the (deterministic) functionality
F (I , J) = ((I ≥ J), (I ≥ J))
in the semi-honest model.
Simple application of oblivious transfer
Consider the problem of privately evaluating a Boolean function f (x, y ), where x is private to Alice and y is private to Bob. This corresponds to privately computing the functionality
F (x, y ) = (f (x, y ), f (x, y )).
We use a slight variant of the one-out-of-two secrets oblivious transfer protocol presented last time: In OT^21 , the secrets are numbered s 0 and s 1. Bob requests and gets the secret of his choice, but Alice does not learn which secret he got. This can be generalized to the case k secrets, where OTk 1 lets Bob choose one out of k.