Verifiable Oblivious PseudoRandom Functions with Public Metadata
Facebook
subodh@fb.com
Facebook
ananthr@fb.com
irtf
cfrg
InternetDraft
This document describes a verifable mechansim to bind public metadata to an
existing Verifiable oblivious PseduoRandom function
(VOPRF). Using zero knowledge proofs a receiver can verify that, for an input
x, a VOPRF(k, x, metadata), is generated from a secret key k, as well as the
given metadata.
Discussion Venues
Discussion of this document takes place on the
Crypto Forum Research Group mailing list (cfrg@ietf.org),
which is archived at .
Source for this draft and an issue tracker can be found at
.
Introduction
A VOPRF allows a client and server to evaluate a psuedorandom function
F(k, x), with secret key k, and input x without the client learning the
key k and the server learning the input x. Additionally in a VOPRF, the
client can verify that the output was computed using the key k.
One challenge in VOPRFs is to be able to bind public metadata to the output
of the VOPRF while keeping the VOPRF both verifiable and oblivious.
Unlike the input x to the VOPRF, public metadata is not meant
to be secret to either the client or the server. This public metadata is
useful in applications where being able to bind application context to a VOPRF
output is criticial to the security of the application.
In this draft we describe a mechanism to bind public metadata to a VOPRF by
deriving the publicprivate keypair that is used by the VOPRF from the
metadata . This method allows the use of existing elliptic
curve VOPRF ciphers while only changing the way the secret key is derived.
Additionally, the key derivation mechanism of the public key can be verified by
a client using noninteractive zeroknowledge proofs to prove that the metadata
specific key is derived from a master secret.
The draft does not describe how metadata is used, but that left to specific
application protocols that use this public metadata mechanism.
Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Terminology
The following terms are used throughout this document.
 PRF: Pseudorandom Function.
 VOPRF: Verifiable Oblivious Pseudorandom Function.
 Client: Protocol initiator. Learns pseudorandom function evaluation as
the output of the protocol.
 Server: Computes the pseudorandom function over a secret key. Learns
nothing about the client's input.
 NIZK: Noninteractive zero knowledge.
 DLEQ: Discrete Logarithm Equality.
Preliminaries
The document defines extensions to the VOPRF required to support metadata.
This document depends on the following:

GG: A primeorder group implementing the API described in
as well as the additional APIs defined below in
.

Public Metadata: The public metadata is defined as an n bit vector. To
represent b values, an application could use log b bits.
PrimeOrder Group Dependency
We define new member functions on the primeorder group GG defined in
:
 ScalarMult(point, scalar): A member function of GG that multiples an
element in the group with a scalar from GF(p).
 NewGenerator(): A member function of GG that samples a new generator
for the group.
Other Conventions
All algorithm descriptions are written in a Pythonlike pseudocode. All
scalar multiplications are performed modulo GF(p).
Discrete log proofs
Zero knowledge proofs for statements on discretelogs were summarized by
. We describe two algorithms used in this draft on GG
to prove discrete log statements.
DLEQProve(k, A, B, C, D) proves that B = k * A and D = k * C without
revealing the value of k. This type of proof is used when k is a secret
value that should not be revealed to a verifier.
DLEQVerify(A, B, C, D, proof) verifies that the proof generated by
DLEQProve is valid.
Protocol
Overview
A server first generates a main key pair (skM, pkM), where skM is the
servers main secret key and pkM is the servers main public key.
Given public metadata t, the server generates a keypair specific to the
metadata t, (skT, pkT) = PKGen(t, skM), where skT is the secret key for
metadata t and pkT is its public key. Once a metadata specific keypair is
available, the server can be used to evaluate a VOPRF(skT, x), where x is
the input for the user. When the VOPRF is in verifiable mode, the client also
receives a NIZK proof that skT and pkT are generated from skM and pkM
(in verifiable mode).
skT, pkT, pkProofs = PKGen(skM, metadata)
evaluatedElement, proof = Evaluate(skT, pkT, blindedElement)
evaluatedElement, pkT, proof, pkProofs
<
pkVerified = PKVerify(pkM, pkT, pkProofs)
output = Finalize(input, blind, evaluatedElement, blindedElement, pkT, proof)
]]>
In the following sections we describe modifications to the VOPRF scheme in
to be able to augment an existing VOPRF with public
metadata.
PreSetup
We augment the offline context setup phase phase of the VOPRF in
. In this phase, both the client and server create a
context used for executing the online phase of the protocol.
Prior to this phase, the key pair
(skM, pkM) should be generated by using MasterKeyGen(metadataBits). This
keypair is used as the master key for VOPRFs. This master key is not used
directly within the VOPRF, however, public metadata is used to generate
attribute specific keys that are used in the VOPRF evaluation.
metadataBits here is the number of bits of metadata that are required for
the application of the VOPRF. MasterKeyGen samples n scalar elements
a0, a1, ... an from the group and a new generator h. ai is a group
element associated with the ith bit of metatadata. Public parameters
are calculated by performing scalar multiplicaton of h with each ai.
Evaluate VOPRF
When client and server have agreed on the metadata to use for the protocol,
the server first executes PKGen(skM, metadata) to generate skT and the
proof that skT is derived from skM. This draft does not discuss how the
client and server agree on the metadata to use, and that is left to the
application.
Note that skM has one group element for each bit of the metadata t, as well
as the extra group element a0. Given metadata t, PKGen calculates the
attribute specific key by performing a scalar multiplication of all the group
elements in skM for each bit of t that is set to 1.
To prove that skT is derived from skM, GenProofs generates upto n
discrete log proofs, one for each bit of the metadata. Each proof proves
that hi = ai * h and Pi = ai * Pi1. This proves that ai was correctly
used for bit i.
Once PKGen has generated a public key for a set of metadata bits,
the client can verify that skT is derived from skM, using
PKVerify(pkM, pkT, pkProofs). This verifies the sequence of discretelog
proofs generated by PKGen.
A server can use skT generated from PKGen as the private key for the
VOPRF mechanism in .
Application considerations
Metadata bits
Applications must choose the maximum size in bits of the metadata that they
would like to support before setup of the protocol. The size of the metdata
impacts the following
 Size of the public key
 Computation time for attribute and proof generation
For b being the number of metadata values needed for an application, the size
of the public key scales as O(log b). Computation also scales as O(log b)
number of scalar multiplications for generating a public key and number of
discrete log proof generations and verifications required.
Encoding metadata
Applications must choose the number of bits of metadata required in order to
be able to represent all possible values for the application's metadata. They
MUST define their own mechanism encode metadata into bits.
Comparison with other approaches
Pairings
It is possible to construct VOPRFs with public metadata using pairingfriendly
curves with an approach in
.
However this approach has some disadvantages. Pairings are not widely
available in cryptographic libraries and are also not compatible with existing
deployed VOPRFs like in . The approach described here
allows applications to use existing deployed VOPRFs while only changing the
mechanism of key derivation.
Partially oblivious PRF
Another approach that could be used to bind metadata to a VOPRF evaluation is
to use a similar method in which uses a regular PRF(k, metadata)
to derive a secret key based on the metadata which is then used in the VOPRF.
The verifiability of public key could be achieved by publishing every public
key for each metadata value in a central repository, which could be checked by
the client. For large number of values of metadata b, this approach
generates O(b) keys, which can be difficult for clients and servers to
manage. In contrast, the approach described in this document, the size of the
master public key is O(log b), and the public keys of each attribute can be
verified against the master key later.
Security Considerations
Cryptographic security
The security properties of a VOPRF with public metadata are derived from the
proof in that the VOPRF defined here is a PRF even after
giving an adversary access to proofs from PKGen. The VOPRF defined in
when combined with attributes results in a PRF output
of PRF(skM, t, x) = a0^t1 * a1^t2 ... * an^tn * H(x).
nDiffie Hellman exponent assumption
There are several variants of the DiffieHellman assumption and the proof of
the VOPRF with public metadata is based on the nDiffie Hellman exponent
assumption. The nDHE problem requires an adversary to distinguish the n+1th
power of a secret a hidden in the exponent from a random element in GG.
Sample uniformly at random d in {0,1}, and a random r from GF(p):
 Given G is a generator in GG
 Given G, a * G , (a^2) * G, ..., (a^n) * G
 if d == 0: C = a^(n+1) * G else: C = r * a
Output d' == d
Selective security vs full security
The security properties of the VOPRF with public metadata described in this
draft is based on the proof in that the VOPRF is a
selectivelysecure VRF. Selectivesecurity is a weaker notion of security that
requires an adversary to commit to the challenge input (in this case, the
metadata and value x) before trying to break the PRF.
In practice, if target inputs are independent of the system parameters, there
should not be an advantage to allowing the attacker to choose the target after
seeing system parameters. To convert our VOPRF with public metadata to one
satisfying a full security notion in the random oracle model, we require that
the metadata be hashed with a collisionresistant hash function with
sufficiently large output (>=256bits). For smaller metadata sets therefore,
the selectivelysecure VRF is much more efficient.
IANA Considerations
This document has no IANA actions.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Oblivious Pseudorandom Functions (OPRFs) using PrimeOrder Groups
Cloudflare
Cloudflare
Cloudflare
An Oblivious Pseudorandom Function (OPRF) is a twoparty protocol for
computing the output of a PRF. One party (the server) holds the PRF
secret key, and the other (the client) holds the PRF input. The
'obliviousness' property ensures that the server does not learn
anything about the client's input during the evaluation. The client
should also not learn anything about the server's secret PRF key.
Optionally, OPRFs can also satisfy a notion 'verifiability' (VOPRF).
In this setting, the client can verify that the server's output is
indeed the result of evaluating the underlying PRF with just a public
key. This document specifies OPRF and VOPRF constructions
instantiated within primeorder groups, including elliptic curves.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
PairingFriendly Curves
Lepidum
NTT
NTT
Stanford University
Pairingbased cryptography, a subfield of elliptic curve
cryptography, has received attention due to its flexible and
practical functionality. Pairings are special maps defined using
elliptic curves and it can be applied to construct several
cryptographic protocols such as identitybased encryption, attribute
based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu
proposed an efficient number field sieve algorithm named exTNFS for
the discrete logarithm problem in a finite field. Several types of
pairingfriendly curves such as BarretoNaehrig curves are affected
by the attack. In particular, a BarretoNaehrig curve with a 254bit
characteristic was adopted by a lot of cryptographic libraries as a
parameter of 128bit security, however, it ensures no more than the
100bit security level due to the effect of the attack. In this
memo, we list the security levels of certain pairingfriendly curves,
and motivate our choices of curves. First, we summarize the adoption
status of pairingfriendly curves in standards, libraries and
applications, and classify them in the 128bit, 192bit, and 256bit
security levels. Then, from the viewpoints of "security" and "widely
used", we select the recommended pairingfriendly curves considering
exTNFS.
Informative References
PrivateStats, DeIdentified Authenticated Logging at Scale
Proof Systems for General Statements about Discrete Logarithms
The Pythia PRF Service
Threshold PartiallyOblivious PRFs with Applications to Key Management
Acknowledgments
TODO acknowledge.