Could ECDH-OPRF-PSI support oblivious transfer？

[HaoXuan40404]

It is possible to utilize the OPRF-PSI algorithm to implement a K-V-PIR protocol, as follows: Alice wishes to inquire about the values corresponding to (xi, xj), while Bob possesses data in the form of (x1, y1), (x2, y2), ..., (xn, yn). Both parties would engage in the OPRF-PSI protocol, such as ECDH. In this process, Bob employs his personal key_b to encrypt the y_i data and subsequently transmits (c_y1, ..., c_yn) to Alice. Alice, in turn, uses her OPRF key_a to decrypt the data. For instance, Alice forwards H(xi)^a to Bob, who computes H(xi)^ab and returns it to Alice. Subsequently, Alice obtains H(xi)^b, which serves as the key for c_yi. It is also possible to enhance this specific implementation by incorporating additional MAC mechanisms for data verification.

[ladnir]

In general this should work. So if the oprf outputs zi, you can compute

(zi1, zi2) = H(zi)

Where H is a hash function or similar.

The sender can send zi1, (yi +zi2). The receiver will look for matching zi1's and if found decrypt the associated value.

Can you add a MAC? Yes, yi can be anything you want. But depending on how it's used it might be a bit subtle. What are you wanting to use these MAC s for? An mpc?

[HaoXuan40404]

I want to use it in the web browser， someone can get value from another server， and the server does not know which key is choose If this approach is feasible, can we also implement a 1-out-of-2 Oblivious Transfer (OT) using a similar method?

[ladnir]

I guess the simplest solution is for yi=(vi, sign(k, vi)), where sign is some digital signature. Then anyone can check the signature of vi to know that it's actually from the server.

This will work for basically any ot or psi protocol.

[HaoXuan40404]

[HaoXuan40404]

For this, Alice wants to get some message from Bob, but does not want bob to know which one she gets

[ladnir]

I don't see why you want to use a DDH type of solution.

ok, let's start with the OPRF abstraction.

1. The sender samples OPRF key k.
2. for each yi, the sender computes yi' = F(k,yi).
3. for each xi, they run the oprf protocol. The receiver learns xi' = F(k,xi).
4. The sender computes (yi1*,yi2*) = H(yi')
5. The sender computes ci = mi + yi2*
6. The sender sends (yi1*, ci) to the receiver.
7. The receiver computes (xi1*,xi2*) = H(xi')
8. The receiver looks for the j s.t. xi1* = yj1*. a. The receiver computes mj = cj - xi2'

How to implement the OPRF? you can use the DDH one.

1. The receiver sends zi = H(xi)^r for some random r
2. The sender sends back vi = zi^k
3. The receiver computes F(k,xi) = H(xi, vi^{1/r}). Note, F(k,xi)=H(xi, H(xi)^k)

If you want better computational efficiency, you can use the OPRF provided by VOLE-PSI. Or you can basically use any PSI protocol. For example, one way to view KKRT is that is "almost" an OPRF. Where is fails is that the sender gets three OPRF outputs for each yi. The receiver will learn one of these but which is basically random. So you can modify the protocol so that if the receiver learns any of the oprf outputs for yi, then they can decrypt mi.

I think your thing might work as well but didn't look super closely. I wouldn't call H(yi^b) a MAC per se.

Then, if you want some third party to be able to verify that the receiver did in fact learn mi from the sender, you can have mi contain the message and a signature from the sender.

[HaoXuan40404]

I apologize for the confusion. What I meant to convey is that Alice can determine which data to decrypt using an identifier, rather than a MAC. I understand now, so this method is secure but not very efficient. Can I use a more efficient OPRF protocol to optimize this approach, is that correct?

[ladnir]

I think that's right.

[HaoXuan40404]

Thank you very much for your patient response!