Talk:Oblivious transfer

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.

Cryptography: Computer science

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
???	This article has not yet received a rating on the importance scale.
	This article is supported by WikiProject Computer science.

Oblivious transfer

Copied from Wikipedia:Reference desk archive/September 2004 I — Matt 01:00, 28 Nov 2004 (UTC)

Could somebody explain this concept to me? Why is it a primitive for secure communication? (BTW: There is an article oblivious transfer but it is only a stub. So maybe write your answer right there.) Thanks a lot in advance. Simon A. 09:05, 31 Aug 2004 (UTC)

1-2 oblivious transfer bug

In the explanation given, the receivers knows x0 and x1 and v so in the same way it got k_b it can get k_(1-b) and then get the value of the m_(1-b) ! This breaks the oblivious transfer concept. Can someone clear that out ? Thanks. Mohammad Al-Aggan (talk) 00:44, 11 January 2010 (UTC)[reply]

The receiver only knows its own random number

k

which due to the protocol is equal to

k_{b}

. From steps 3 and 4 we have:

{\begin{array}{lcl}v&=&enc(k)+x_{b}\\k_{i}&=&dec(v-x_{i})\end{array}}

Indeed

k_{b}=dec(v-x_{b})=dec(enc(k))=k

but

k_{1-b}=dec(enc(k)+x_{b}-x_{1-b})

will decrypt to rubbish that is not knowable to the receiver by virtue of the asymmetric encryption used. Limninal (talk) 11:04, 20 February 2010 (UTC)[reply]

1-2 OT Even, Goldreich, and Lempel Reference?

What is the reference for the RSA-based algorithm presented, claiming to be inspired by Even, Goldreich, and Lempel? Docfink (talk) 17:03, 27 April 2015 (UTC)[reply]

Even, S., Goldreich, O., Lempel, A., "A Randomized Protocol for Signing Contracts", 1985, available for example at https://dl.acm.org/doi/pdf/10.1145/3812.3818 203.215.133.188 (talk) 04:15, 10 May 2022 (UTC)[reply]

1-2 OT Algorithm Assumption

Also needed is the assumption that Alice verifies that $k_{0}\neq k_{1}$ in step 6, otherwise it shows that Bob has selected a $k$ such that $(x_{0}+k^{e})=(x_{1}+k^{e})~mod~N$ enabling him to decrypt both choices. Docfink (talk) 17:03, 27 April 2015 (UTC)[reply]

1-2 OT Concrete Example

Suggest a hands-on example to highlight the protocol:

A big-box retailer offers one of two discount codes to a consumer to be redeemed later at the register. The retailer offers a choice of one of "15% off entire order" or "$50 bonus cash" for use on a future purchase. Using the 1-2 OT protocol, the consumer commits to a choice of one of these two, sends his selection to the retailer, and the retailer issues the discount code encoded with the consumer's choice. This all happens in such a way that the retailer does not learn the consumer's preference, yet the retailer incurs the cost of only one of the promotions, not both. (We assume that the consumer wisely pays in cash at the register, to keep his preferences private.)

Docfink (talk) 17:03, 27 April 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Oblivious transfer. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive https://web.archive.org/20120205053135/http://www.wisdom.weizmann.ac.il/~reingold/publications/AIR.PS to http://www.wisdom.weizmann.ac.il/~reingold/publications/AIR.PS

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 14:54, 9 February 2016 (UTC)[reply]

Oblivious transfer "importance of applications"

"Further work has revealed oblivious transfer to be a fundamental and important problem in cryptography. It is considered one of the critical problems in the field, because of the importance of the applications that can be built based on it. In"

This section doesn't explain what the actual applications are (other than possibly "multiparty computing"?), why they are important. Furthermore a new sentence seems to have started and has never been finished, only "In" remains of it. — Preceding unsigned comment added by Owlstead (talk • contribs) 10:08, 23 February 2021 (UTC)[reply]

Comments moved from article

There seems to be some error. The decryption can be done only by those who has the secret key. Here the party who generates key is Alice. And it is bob who decrypts. Something wrong in the algorithm. please correct. — Preceding unsigned comment added by 2607:fea8:e920:f090:3dd6:4e22:a8c2:9100 (talk) 19:45, 17 March 2022 (UTC) --Ahecht (TALK[reply]
PAGE) 20:03, 17 March 2022 (UTC)