When submitting ``Coin-Flipping-based Quantum Oblivious Transfer'' (quant-ph/0605027v4) to Indocrypt-2006, I received valuable reviews. Due to the attacks in these reviews, my major protocols, for cheat-sensitive and coin-flipping-based 2-1 oblivious transfers, are insecure. I would have withdrawn the paper. But I think I'd rather post the attacks made by the reviewer. Besides, as ``coin-flipping-based 2-1 OT'' is an important case-study in ``Two-party Models and the No-go Theorems'' (quant-ph/0608165), the paper is also touched by the attack. It will be reconsidered, and the case-study will be eliminated from it. I would like to thank the ``anonymous'' reviewer for those valuable attacks and comments.
Oblivious Transfer(OT) protocol is an important primitive for designing cryptographic protocols.Designing OT protocol from bilinear pairing not only extends the bilinear pairing application but also increases the design technique of OT,which has important practical significance.This paper utilizes bilinear pairing to design a k-out-of-n OT protocol.The new protocol can protect both receiver’s privacy and sender’s privacy.The new protocol also can resist impersonation attacks,replay attacks and man-in-the-middle attacks.It can be used in an insecure channel,and the protocol has high efficiency.
In the Comment the author states that the proposed all-or-nothing oblivious transfer (OT) protocol in our paper is insecure against a dishonest Alice and, as a corollary, derives an attack to Cr\'epeau's construction of 1-out-of-2 OT. The security criterion used in the Comment is indeed stronger than the one used in our paper. However, we argue that the criterion used in our paper is in the spirit of the original idea of the OT protocol proposed by Rabin. Moreover, a protocol that satisfies the criterion in our paper can be used to construct useful multiparty protocols. Finally, the protocol in our paper can be used, together with a secure bit commitment scheme, to construct a 1-out-of-2 OT secure against malicious Alice, achieving the security requirement considered in the Comment.