Download Applied Cryptography Lecture Notes: Oblivious Transfer and more Lecture notes Cryptography and System Security in PDF only on Docsity!
University of Illinois, Urbana Champaign CS/ECE 498AC3/4 Applied Cryptography
Instructor: Dakshita Khurana Scribe: Mohammad Behnia Date: September 29, 2020
LECTURE
Oblivious Transfer
In this lecture we will introduce the concept of secure computation. In a transition out of our discussions of zero knowledge, we will explore methods of performing computation on encrypted data in a secure manner. So far, we have explored ways to facilitate secure com- munication (various encryption systems) followed by methods to show proof of encryption without revealing any secrets (using zero-knowledge to enable such proofs). Now moving onto secure computation, the high-level goals will be to reveal some partial results to the involved parties while hiding sensitive information we do not want specific parties to recover. The first part of this lecture involves setting up a scenario where Alice and Bob want to engage in an oblivious transfer. We will explore this model using an ideal trusted party as a mediator and a real-world view without the mediator. We will look at different types of adversaries that will challenge any protocols we construct. Finally, we will look at a secure construction and begin to formulate our security proofs.
20.1 Oblivious Transfer
Oblivious transfer is a cryptography primitive under which a sender transfers one of many choices of information but remains oblivious to which one was chosen. Let’s take a first look at an example of oblivious transfer. Consider the scenario with a sender Alice, and receiver Bob depicted in Figure 20.1. Alice has two messages m 0 and m 1 , and Bob has some binary choice denoted by bit b. The goal is for Bob to receive exactly one of m 0 and m 1 depending on bit b. The chosen message will be denoted as mb. Under the ideal construction, we will have a trusted authority that will mediate this exchange. Alice will send m 0 and m 1 to the authority and in return receive an acknowledgement that the exchange has completed. Bob will send bit b to the authority and receive a message mb. In this scheme, both Alice and Bob only receive partial information from the trusted authority (Alice receives the acknowledgement signal and Bob receives only mb). Beyond the multiplexer functionality, we care about the security of the oblivious transfer. In particular, we would like Alice to have no idea about the value of bit b (which we should be able to formally prove using the two-game adversary model), and Bob to have no idea about the contents of the message that was not selected: m 1 −b. Under the trusted authority model both of these goals are satisfied, but the question remains if we can guarantee these security goals without the trusted authority.
Figure 20.1: An ideal model of oblivious transfer between Alice and Bob.
20.2 An Honest Protocol
This will be our first attempt at creating an oblivious transfer protocol for Alice and Bob assuming they are honest parties. We will explore the definition of “honesty” and alterna- tive adversary models after completing this construction. The goal of this construction is to create a groundwork for a functional protocol.
The high-level idea is to have Bob sample two public keys pk 0 and pk 1. Alice will then encrypt each message using its corresponding public key and return ciphertexts to Bob. Bob, however, should only be able to decrypt one of the encrypted messages. Using the El-Gamal key exchange scheme we will define the construction as follows:
- For choice of bit b, Bob will sample pkb = gαb^. Set pk 1 −b = g′, a random group element for which we do not know the discrete log. By hardness of discrete logarithm and Diffie-Hellman problem, Bob should not be able to have access to corresponding private key.
- Bob sends Alice the two public keys: pkb and pk 1 −b.
- From Alice’s view, she receives pk 0 = gα^0 and pk 1 = gα^1. Alice will encrypt each message with a different public key. Using gβ^0 and gβ^1 , compute H(gα^0 β^0 ) ⊕ m 0 and H(gα^1 β^1 ) ⊕ m 1.
- Alice sends Bob gβ^0 , H(gα^0 β^0 ) ⊕ m 0 and gβ^1 , H(gα^1 β^1 ) ⊕ m 1.
- Bob will be able to decrypt mb using the key-pair for pkb he sampled. Bob will not be able to recover the message that was encrypted using pk 1 −b.
If Bob follows the protocol for generating the two public keys and Alice is not able to dis- tinguish the two public keys, this will be a sound protocol. However if Bob is not honest and samples both key-pairs, the adversarial Bob will be able to recover both messages.
Figure 20.2: An adversarial receiver interacting with the simulator.
Figure 20.3: An adversarial sender interacting with the simulator.
Note, we can also create this simulator model for the context of a malicious sender (Alice). In this case, the simulator will be between Alice and the trusted authority, with a transcript with Alice and sending m 0 and m 1 and receiving acknowledgement from the trusted author- ity. One observation from this construction is that the simulator must be able to find m 0 and m 1 independent of b, since simulator has no knowledge of bit b. It follows, that Alice’s behavior in the real game must also be independent of the Bob’s choice of bit b.
20.4 Oblivious Transfer Protocol
This construction is similar to a work [1] in which El-Gamal encryption is employed. Further security analysis under adversarial Alice/Bob are presented in the paper.
Consider Bob has some input bit b.
- Sample (pk, sk) key-pair using encryption algorithm of choice.
- Sample r 0 ∈ { 0 , 1 }n^ uniformly at random, and compute H(r 0 ). (where H(x) refers to the hash output of a random oracle)
- Set r 1 = H(r 0 ) ⊕ pk. (Note: pk = r 1 ⊕ H(r 0 ))
- Set p′ k = r 0 ⊕ H(r 1 ). (Note: Bob does not know s′ k)
- If b == 0, set s 0 = r 0 and s 1 = r 1 , else if b == 1, set s 0 = r 1 and s 1 = r 0.
Alice receives s 0 and s 1 from Bob.
- Compute pk 0 = H(s 0 ) ⊕ s 1
- Compute pk 1 = H(s 1 ) ⊕ s 0
- Ciphertext ct 0 = Encpk 0 (m 0 )
- Ciphertext ct 1 = Encpk 1 (m 1 )
Alice sends ct 0 and ct 1 to Bob.
Bob knows exactly one (pk, sk) pair, corresponding to mb. For b == 0, Bob can recover m 0 , and for b == 1 Bob can recover m 1.
We will address some underlying assumptions and initial questions about this protocol.
- Why is Alice not able to distinguish a regularly sampled key-pair as opposed to a seemingly random n-bit string?
Assumption 20.1. A public key encryption scheme with pseudorandom public keys (or mapping thereof) is selected.
- Can Bob send pk 0 and pk 1 instead of s 0 and s 1? Alice needs to be able to confirm these public keys are generated using this XOR scheme otherwise a malicious Bob can send two public keys for which he knows both private keys.
- Why does r 0 need to be a random sample? To ensure indistinguishability of s 0 and s 1 from Alice’s perspective. There would be issues if Bob had some deterministic choice of r 0.
20.5 Motivating the Proof
We will begin to look at what the simulator must do and look at some constructions that we will revisit next lecture to finalize our proof of view-indistinguishability.
Consider security against a malicious Alice:
The simulator sends s˜ 0 and s˜ 1 to Alice and receives ct˜ 0 and ct˜ 1. The simulator should be able to decrypt both ciphertexts and send m 0 and m 1 to the trusted authority. To enable this, the simulator will have control of the random oracle (programmability of oracle hash output values). This can be achieved if the simulator samples s˜ 0 and s˜ 1 such that they will
know the sk˜ 0 and sk˜ 1 corresponding to ˜pk 0 and pk˜ 1. One approach is for the simulator to randomly sample s˜ 0 and s˜ 1 and set H( s˜ 0 ) = ˜pk 0 ⊕ s˜ 1 and H( s˜ 1 ) = pk˜ 1 ⊕ s˜ 0. To prove indistinguishability, one would need to show the view of Alice observing s˜ 0 and s˜ 1 sampled uniformly at random and her interactions with the random oracle (with the outputs set accordingly) is indistinguishable from the real world transaction with Bob (next lecture).
