Cryptology ePrint Archive: Report 2008/163

Universally Composable Adaptive Oblivious Transfer

Matthew Green and Susan Hohenberger

Abstract: In an oblivious transfer (OT) protocol, a Sender with messages M_1,...,M_N and a Receiver with indices s_1,...,s_k interact in such a way that at the end the Receiver obtains M_{s_1},...,M_{s_k} without learning anything about the other messages, and the Sender does not learn anything about s_1,...,s_k. In an adaptive protocol, the Receiver may obtain M_{s_{i-1}} before deciding on $s_i$. Efficient adaptive OT protocols are interesting both as a building block for secure multiparty computation and for enabling oblivious searches on medical and patent databases.

Historically, adaptive OT protocols were analyzed with respect to a ``half-simulation'' definition which Naor and Pinkas showed to be flawed. In 2007, Camenisch, Neven, and shelat, and subsequent other works, demonstrated efficient adaptive protocols in the full-simulation model. These protocols, however, all use standard rewinding techniques in their proofs of security and thus are not universally composable. Recently, Peikert, Vaikuntanathan and Waters presented universally composable (UC) non-adaptive OT protocols (for the 1-out-of-2 variant). However, it is not clear how to preserve UC security while extending these protocols to the adaptive k-out-of-N setting. Further, any such attempt would seem to require O(N) computation per transfer for a database of size N. In this work, we present an efficient and UC-secure adaptive k-out-of-N OT protocol, where after an initial commitment to the database, the cost of each transfer is constant. Our construction is secure under bilinear assumptions in the standard model.

Category / Keywords: cryptographic protocols / oblivious transfer, UC security, bilinear maps

Publication Info: To appear in ASIACRYPT 2008.

Date: received 10 Apr 2008, last revised 14 Sep 2013

Contact author: mgreen at cs jhu edu

Available format(s): PDF | BibTeX Citation

Note: Added a clarification on page 10 regarding the security of a signature variant we used.

Version: 20130914:212259 (All versions of this report)

Short URL: ia.cr/2008/163

Discussion forum: Show discussion | Start new discussion