Oblivious pseudorandom function

Uses your system voice; voice and rate in settings.

Snapshot

≈ 4 min read

Names in other languages

No names in other languages are held for this entry yet.

Article bodies are English and are not machine-translated. A name in another language is not a translation of the article.

An oblivious pseudorandom function (OPRF) is a cryptographic function, similar to a keyed-hash function, but with the distinction that in an OPRF two parties cooperate to securely compute a pseudorandom function (PRF).

An oblivious pseudorandom function (OPRF) is a cryptographic function, similar to a keyed-hash function, but with the distinction that in an OPRF two parties cooperate to securely compute a pseudorandom function (PRF). The parties compute: O = OPRF(I, S) The first party (the client), knows the input (I) and learns the output (O) but does not learn the secret (S) The second party (the server), knows the secret (S), but does not learn either the input (I), nor the output (O). The function has the same security properties as any (cryptographically secure) pseudorandom function. Specifically it shall be hard to distinguish the output from true randomness. The function is called an oblivious pseudorandom function, because the second party is oblivious to the function's output. This party learns no new information from participating in the calculation of the result. However, because it is only the second party that holds the secret, the first party must involve the second party to calculate the output of the pseudorandom function (PRF). This requirement enables the second party to implement access controls, throttling, audit logging and other security measures. byte[] computeOPRF(byte[] input) { // Apply point-hashing algorithm // For example, as described in RFC 9380 ECPoint hashedPoint = hashToPoint(input); // Generate a random blinding factor Scalar b = randomScalar(); // Blind the input via a curve multiply ECPoint blindedInput = ECMultiply(hashedPoint, b); // Send request to server to obtain response ECPoint serverResponse = sendRequest(blindedInput); // Compute multiplicative inverse of b Scalar inverse = modInverse(b); // Unblind the response to produce the result ECPoint result = ECMultiply(serverResponse, inverse); // Hash the unblinded result to complete OPRF calculation return hash(result); } Notes: The client computes the multiplicative inverse of the blinding factor. This enables it to reverse the effect of the blinding factor on the result, and obtain the result the server would have returned had the client not blinded the input. As a final step, to complete the OPRF, the client performs a one-way hash on the result to ensure the OPRF output is uniform, completely pseudorandom, and non-invertible. ECPoint processRequest(ECPoint blindedInput, Scalar secret) { // Apply secret to compute the response ECPoint response = ECMultiply(blindedInput, secret); return response; } It then returns the response, which is the blinded output, to the client. Notes: Because the elliptic curve point multiplication is computationally difficult to invert (like the discrete logarithm problem, the client cannot feasibly learn the server's secret from the response it produces. Note, however, that this function is vulnerable to attacks by quantum computers. A client or third party in possession of a quantum computer could solve for the server's secret knowing the result it produced for a given input. When using OPRFs based on elliptic curve or Diffie–Hellman, knowing the public key y = g x it is possible to use a second request to the OPRF server to create a zero-knowledge proof of correctness for the previous result. The parties compute: O = POPRF(H, E, S) The first party (the client), knows the hidden input (H) and the exposed input (E) and learns the output (O) but does not learn the secret (S) The second party (the server), knows the secret (S), and learns the exposed input (E), but does not learn either the hidden input (H), nor the output (O). The use case for this is when the server needs to implement specific throttling or access controls on the exposed input (E), for example, (E) could be a file path, or user name, for which the server enforces access controls, and only services requests when the requesting user is authorized. A P-OPRF based on bilinear pairings was used by the "Pythia PRF Service". Recently, versions of P-OPRFs not based on pairings have appeared, such as a version standardized in the IETF RFC 9497, as well in its more recent improvement.

Text derived from https://en.wikipedia.org/w/index.php?oldid=1299954345 under CC BY-SA 4.0; modifications have been made.

Sources cited in this revision

Extracted from the cited revision's reference blocks; absent citations are not invented.