Oblivious Transfer based on Key Exchange

Key-exchange protocols have been overlooked as a possible means for implementing oblivious transfer (OT). In this paper we present a protocol for mutual exchange of secrets, 1-out-of-2 OT and coin flipping similar to Diffie-Hellman protocol using the idea of obliviously exchanging encryption keys. Since, Diffie-Hellman scheme is widely used, our protocol may provide a useful alternative to the conventional methods for implementation of oblivious transfer and a useful primitive in building larger cryptographic schemes.

💡 Research Summary

The paper proposes a family of cryptographic protocols that derive oblivious transfer (OT) and related primitives directly from a modified Diffie‑Hellman (DH) key‑exchange mechanism. The central idea is to make the DH exchange itself “oblivious”: Alice and Bob each secretly pick one of two square‑root values g₁ or g₂ (both satisfying gᵢ² ≡ c (mod p) for a publicly agreed prime p and generator x). They then exchange the usual DH values p^{x·N}·gᵢ (mod p) using fresh random nonces N_A and N_B. If both parties happen to choose the same g, the resulting shared secret K is identical; if they choose different g’s, the derived keys differ. Because the choice of g is random and private, the probability of a match is exactly ½, and neither party can learn whether the other’s choice matched theirs.

Building on this “oblivious key exchange”, the authors describe a protocol for mutual secret exchange. After the DH phase each party encrypts its secret with the derived key (or its complement) and sends the ciphertext. Additional XOR‑masked values are exchanged to allow each side to verify whether the other actually obtained the key, without revealing the key itself. The analysis shows that an adversary who intercepts the exchanged DH values would need to solve a discrete logarithm (DLP) to recover the private nonces, which is assumed infeasible for suitably large p (≥1024 bits).

The paper then adapts the construction to 1‑out‑of‑2 OT. Alice prepares two secrets S₁ and S₂, encrypting each with a distinct key K₁, K₂ that correspond to the two possible g‑choices. Bob selects the g that matches the secret he wants, runs the oblivious DH exchange, and consequently obtains only the matching key. Alice never learns which g Bob selected, so she cannot tell which secret Bob retrieved.

A coin‑flipping protocol is obtained by interpreting the outcome of the oblivious DH exchange as the coin result: if the keys match, Bob wins; otherwise Alice wins. After Bob announces his key, Alice reveals all her random choices, allowing Bob to verify that the result was not tampered with. This approach replaces traditional commitment‑based coin‑flipping schemes while preserving fairness.

Finally, the authors present a zero‑knowledge proof (ZKP) based on the same group. The prover selects a random n and sends X = g^{e·n} (mod p). The verifier challenges with a random bit b. If b = 0, the prover reveals n; if b = 1, the prover sends Y = g^{e·m} for a fresh random m. Repeating the challenge reduces the cheating probability exponentially (½ per round). The soundness of the ZKP rests again on the hardness of the DLP.

Security analysis throughout the paper hinges on the difficulty of solving the discrete logarithm problem and, for the OT variants, the Decision Diffie‑Hellman problem. The authors argue that an adversary cannot deduce the private nonces or the chosen g without solving these problems, and that the protocol remains secure against both passive eavesdroppers and an active, malicious counterpart, assuming authenticated channels (digital signatures) are used.

In conclusion, the work demonstrates that the classic Diffie‑Hellman key‑exchange, when suitably randomized, can serve as a versatile building block for oblivious transfer, 1‑out‑of‑2 OT, fair coin flipping, and discrete‑log‑based zero‑knowledge proofs. This perspective had been largely overlooked, and the proposed constructions offer a conceptually simple, potentially more efficient alternative to existing OT schemes that rely on RSA, ElGamal, or more complex DDH‑based protocols. Future work is suggested on concrete parameter selection, implementation issues (randomness quality, side‑channel resistance), and extensions to multi‑party settings.