Oblivious pseudorandom function: Difference between revisions

Content deleted Content added
m Added link to Homomorphic Encryption
Added section for private-set-intersection
Line 1:
{{Short description|A function computed by two parties that emulates a random oracle.}}
 
An '''Oblivious Pseudorandom Function''' (OPRF) is a [[Cryptography|cryptographic]] function, similar to a [[HMAC|keyed-hash function]], but with the distinction that an OPRF is [[Secure_multi-party_computation|cooperatively computed]] by two parties.<ref name="oprf">{{cite journal |last1=Casacuberta |first1=Sílvia |last2=Hesse |first2=Julia |last3=Lehmann |first3=Anja |title=SoK: Oblivious Pseudorandom Functions |journal=Cryptology ePrint Archive |date=2022 |volume=Paper 2022/302 |url=https://eprint.iacr.org/2022/302}}</ref>
 
== OverviewFormal Definition ==
 
An Oblivious Pseudorandom Function (OPRF) is a [[Cryptography|cryptographic]] function, similar to a [[HMAC|keyed-hash function]], but with the distinction that an OPRF is [[Secure_multi-party_computation|cooperatively computed]] by two parties.<ref name="oprf">{{cite journal |last1=Casacuberta |first1=Sílvia |last2=Hesse |first2=Julia |last3=Lehmann |first3=Anja |title=SoK: Oblivious Pseudorandom Functions |journal=Cryptology ePrint Archive |date=2022 |volume=Paper 2022/302 |url=https://eprint.iacr.org/2022/302}}</ref>
 
Specifically, an OPRF is any function with the following properties:
Line 13:
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_family|Pseudorandom Function]] (PRF). This requirement enables the second-party to implement [[Access_control|access controls]], [[Rate_limiting|throttling]], and or other security measures.
 
This requirement enables the second-party to implement [[Access_control|access controls]], [[Rate_limiting|throttling]], and or other security measures.
 
__TOC__
Line 27 ⟶ 25:
OPRFs have many useful applications in [[cryptography]] and [[information security]].
 
These include [[PBKDF2|password-based key derivation]], andpassword-based [[key agreement]], password-hardening, untraceable [[CAPTCHA|CAPTCHAs]], [[Password_manager|password management]], and [[Homomorphic_encryption|homomorphic]] [[key management]], and [[Private_set_intersection|private set intersection]].<ref name="oprf"/><ref>{{cite web |last1=Krawczyk |first1=Hugo |title=Oblivious Pseudorandom Functions and Some (Magical) Applications |url=https://www.cs.columbia.edu/~tal/4261/F19/hugo-columbia-oprf.pdf |publisher=Columbia University |access-date=31 January 2024}}</ref>
 
An OPRF can be viewed as a special case of [[homomorphic encryption]], as it enables another party to compute a function over an [[Ciphertext|encrypted input]] and produce a result (which remains encrypted) and thereby it learns nothing about what it computed.
Line 39 ⟶ 37:
If the secret key used in the OPRF is high-entropy, then the output of the OPRF will also be high-entropy. This thereby solves the problem of the password being low-entropy, and therefore vulnerabile to [[Password_cracking|cracking]] via [[brute-force attack|brute force]].
 
This technique is called ''Password-Hardening''.<ref>{{cite book |last1=Ford |first1=W. |last2=Kaliski |first2=B. S. |chapter=Server-assisted generation of a strong secret from a password |title=Proceedings IEEE 9th International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE 2000)|date=2000 |pages=176–180 |doi=10.1109/ENABL.2000.883724 |isbn=0-7695-0798-0 |s2cid=1977743 |chapter-url=https://ieeexplore.ieee.org/document/883724}}</ref> It fills a similar purpose as [[Key_stretching|key stretching]], but password-hardening adds significantly more entropy.
 
Further, since each attempt at guessing a password that is hardened in this way requires interaction with a server, it prevents an [[offline attack]], and thus enables the user or system administrator to be alerted to any password-cracking attempt.
Line 84 ⟶ 82:
For example, an OPRF enables a key-management system to issue [[Key_(cryptography)|cryptographic keys]] to authenticated and authorized users, without ever seeing, learning, or being in a position to learn, any of the keys it provides to users<ref>{{cite book |last1=Jarecki |first1=Stanislaw |last2=Krawczyk |first2=Hugo |last3=Resch |first3=Jason |chapter=Updatable Oblivious Key Management for Storage Systems |date=2019 |title=Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security |volume=November 2019 |pages=379–393 |doi=10.1145/3319535.3363196 |isbn=978-1-4503-6747-9 |chapter-url=https://dl.acm.org/doi/10.1145/3319535.3363196 |access-date=Jan 27, 2024}}</ref>.
 
=== Private Set Intersection ===
 
[[Private set intersection]] is a cryptographic technique that enables two or more parties to compare their private sets to determine which entries they share in common, but without disclosing any entires which they do not hold in common.
 
For example, private set intersection could be used by two users of a social network to determine which friends they have in common, without revealing the identities of friends they do not have in common. To do this, they could share the outputs of an OPRF applied to the friend's identity (e.g., the friend's phone number or e-mail address).
 
The output of the OPRF cannot be inverted to determine the identity of the user, and since the OPRF may be [[Rate_limiting|rate-limited]], it will prevent a brute-force attack (e.g., iterating over all possible phone numbers).<ref>{{cite journal |last1=Chase |first1=Melissa |last2=Miao |first2=Peihan |title=Private Set Intersection in the Internet Setting from Lightweight Oblivious PRF |journal=IACR in CRYPTO 2020 |date=Aug 2020 |volume=Advances in Cryptology – CRYPTO 2020: 40th Annual International Cryptology Conference |issue=Proceedings Part III |pages=34-63 |doi=10.1007/978-3-030-56877-1_2 |url=https://dl.acm.org/doi/10.1007/978-3-030-56877-1_2}}</ref>
 
== Implementations ==