$\textsf{PERKS}$: Persistent and Distributed Key Acquisition for Secure Storage from Passwords

Abstract

We investigate how users of instant messaging (IM) services can acquire strong encryption keys to back up their messages and media with strong cryptographic guarantees. Many IM users regularly change their devices and use multiple devices simultaneously, ruling out any long-term secret storage. Extending the end-to-end encryption guarantees from just message communication to also incorporate backups has so far required either some trust in an IM or outsourced storage provider, or use of costly third-party encryption tools with unclear security guarantees. Recent works have proposed solutions for password-protected key material, however all require one or more servers to generate and/or store per-user information, inevitably invoking a cost to the users.

We define distributed key acquisition (DKA) as the primitive for the task at hand, where a user interacts with one or more servers to acquire a strong cryptographic key, and both user and server store as little as possible. We present a construction framework that we call $\textsf{PERKS}$—Password-based Establishment of Random Keys for Storage—providing efficient, modular and simple protocols that utilize Oblivious Pseudorandom Functions (OPRFs) in a distributed manner with minimal storage by the user (just the password) and servers (a single global key for all users). Along the way we introduce a formal treatment of DKA, and provide proofs of security for our constructions in their various flavours.

Gareth T. Davies has been supported by the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme, grant agreement 802823. The full version of this article is available at [19].

Appendices

A WhatsApp Encrypted Backup Rollout

In September 2021, WhatsApp announced [41] that they would soon begin beta testing of an encrypted chat and media backup service that uses HSMs and the envelope part of the OPAQUE protocol [28] in a manner that is conceptually similar to a (1, 1)-PPSS. In this subsection we discuss their system based on the details in the WhatsApp whitepaper and NCC Group’s technical report [35] and explain the differences with our work.

OPAQUE is an asymmetric password-authenticated key exchange protocol that is a compiler of three components: an oblivious PRF to turn the user’s password $\textrm{x}$ into a strong secret value $\textrm{y}$, an ‘envelope’ mechanism whereby the user encrypts their AKE key material under $\textrm{y}$ using symmetric encryption, and an AKE protocol. WhatsApp’s approach uses the OPRF and a modified version of the envelope mechanism, but since no key exchange needs to occur the AKE component is dropped completely. In the WhatsApp system, at the point of registration (first ever backup), a client device generates a random 256-bit key $k$ and then stores this as an encrypted record (envelope) in a ‘HSM-based Backup Key Vault’ so that it can later retrieve this key using only their password (PIN or passphrase): the HSM acts as the OPRF server and derives a per-user secret key $\textrm{sk}_{ uid }$ from a single master secret and $uid$ when called. The envelope in the WhatsApp system is $\mathsf {PK.Enc}_{\textrm{pk}.\textrm{HSM}}(\mathsf {SK.Enc}_{\textrm{y}}( k ))$, a public-key encryption of an encryption of $k$ under the OPRF output value $\textrm{y}$. Later on when a user comes online to retrieve the contents of their envelope it is not apparent if this is sent encrypted under some user public key, and it would appear that this PKE scheme is not for protecting the channel, but rather so that the envelopes can be stored outside of the HSM. These envelopes are stored in an integrity-protected manner using a Merkle tree. No security analysis of the system has been provided for the WhatsApp approach, and the only analysis available is the report by NCC Group [35] that does not discuss any formal security requirements for the system.

Intuitively, the WhatsApp approach relies on the tamper-resistant properties of the HSM to make sure that the OPRF key $\textrm{sk}$ (that is used to derive $\textrm{sk}_{ uid }$) is not leaked to any party. If this key is leaked, then an offline adversary can attempt to recover the file encryption key that is contained within the registration envelope. Our approach avoids assuming a HSM on the server side, and instead distributes the trust among a number of servers. An adversary in possession of a stolen client device needs to guess the correct password while avoiding WhatsApp’s rate-limiting mechanisms, and thus performing this type of online attack is similar in our system.

Further, the WhatsApp system requires that the client device generates the user file encryption key $k$ using ‘a built-in cryptographically secure pseudorandom number generator’, however as already stated, this is of no use if the device’s randomness generation is already compromised during registration.

B Using $\textsf{PERKS}$ as a Storage System

We now explain why our approach is well-suited to derivation of a backup key for outsourced storage systems, and particularly for instant messaging. Then, we describe how our construction can be used to build a feature rich file system for cloud storage, incorporating recent work analysing security of symmetric encryption schemes where a user encrypts ‘to themself’, deduplication, and efficient key rotation.

Instant messaging apps are generally free to download and use, and users are often unwilling to pay for additional features. This leaves very little room for manoeuvre when designing a secure backup service: users must use an internal solution like WhatsApp’s (see Appendix A), where the protocol is potentially strong but not open source. A service such as the one we propose needs to be extremely efficient in terms of bandwidth and storage to possibly be offered as a free service: this is why we aim to only use the most efficient OPRFs, and enforce minimal user and server storage. In particular, we envision OPRF services with multiple other roles in addition to $\textsf{PERKS}$, hence our system does not require the OPRF servers to be given a particular (share of a) key, as is done in many prior works [5, 25, 27].

The constructions defined in Sect. 4 allow a user to derive a single symmetric key from a password. It remains to select a symmetric encryption primitive for encryption, a decision that is informed by the desired functionality and security properties.

Note that in the case of long-term encrypted backup, if a user’s device is compromised and they wish to change their encryption key, they may still wish to recover messages stored under the old key (i.e. even if they believe that an adversary is already in possession of those messages). From this perspective, the user may wish to recover their messages after they have already chosen a new password for use with new messages, creating an overlap in the epochs of the system: this is a departure from the regular theoretical approach to key rotation via updatable encryption and we discuss this further below.

Encrypt-to-Self. Pijnenburg and Poettering [36] recently demonstrated that integrity protection can still be obtained in the event of user key corruption: if the user stores short file (ciphertext) hashes then even if the user knows that their key is corrupted they can check ciphertext integrity when downloading files and discard any where the hash does not match a local entry. In the same paper, the authors demonstrated a method to compute these hashes during encryption, to avoid making two passes over plaintext data.

Deduplication. If the user expects to upload some files many times, for example by backing up an entire disk periodically, and wants to avoid storing multiple copies of files then they can employ deduplication techniques such as convergent encryption [38]. File key derivation for a file F could be for example $k _F\leftarrow \textsf{H}( k ||F)$ for some cryptographic hash function $\textsf{H}$.

Key Rotation. If the user wishes to rotate their file encryption key in $\textsf{PERKS}$ then there are three possibilities:

• 1. Use an OPRF service that has automated key rotation, e.g. by using the Pythia OPRF [20]. Note that for the $\textrm{n}$ out of $\textrm{n}$ construction, just one OPRF server updating its $\textrm{sk}_i$ value results in a change in file encryption key. If this is used, then the server will provide ‘tokens’ that work similarly to updatable encryption (UE) update tokens: unblinded values provided under the old key can be efficiently modified to unblinded values under the new key, without the need to call the OPRF service under all the old inputs.

• 2. Use a different password. This will result in new OPRF output values for all OPRF servers. (Note that another credential modification technique is possible via an OPRF service that supports tweaks, i.e. different $uid$ input values for the same user: this will result in different OPRF output values for the OPRF servers offering this.)

• 3. ($\textrm{t}$ out of $\textrm{n}$ construction only) Choose a new key $k$, essentially running $\textrm{setup}$ again. This results in a new key share vector $\vec {\mathrm {\alpha }}$ but the $\textrm{y}_i$ values are unchanged so the user needs to publish a new public vector $\vec {\textrm{SV}}$.

In all of these cases, the user can avoid downloading, decrypting, reencrypting and reuploading all of their files every time they update their file encryption key by utilizing updatable encryption [8, 11, 33], where the user can send a short update token to the ciphertext storage server (CSP) with which the underlying key for the ciphertexts can be rotated efficiently, without leaking information to the CSP. However the challenge is providing availability of key material in consecutive epochs. In the efficient (ciphertext-independent) UE schemes just mentioned, the update token calculation requires knowledge of an old key and a new key at the beginning of the new epoch. For user-initiated actions (items 2 and 3) this is trivial: the user runs the protocol to get their old key, then runs the protocol again using their new inputs, calculates the token, sends that to the file storage server and then deletes both keys locally. In the OPRF server key rotation setting (item 1) care is required: if a new epoch begins while the user does not have a local copy of the file encryption key available then the user would be locked out of access to their ciphertexts. To solve this issue the OPRF services could make a transition period available to users, where access is given to the OPRF functionality for the old and the new OPRF keys.

C Secret Sharing Schemes

We define a secret sharing scheme $\textrm{SSS}$, that allows an entity to share some secret value $k$ among $\textrm{n}$ parties, such that any $\textrm{t}$ of the shares enable reconstruction of $k$, while any set of $\textrm{t}-1$ shares reveals nothing about $k$. The exposition here is adapted from Boneh and Shoup [9].

A secret sharing scheme $\textrm{SSS}=(\textrm{SecShare},\textrm{SecCombine})$ over a finite set $\mathrm {S_1}$ consists of two algorithms. Sharing algorithm $\textrm{SecShare}( k ,\textrm{t},\textrm{n})$ is probabilistic, taking as input $k \in \mathrm {S_1}$ for $0\le \textrm{t}\le \textrm{n}$ and returning shares $\vec {\mathrm {\alpha }}=\{\mathrm {\alpha }_1,\dots ,\mathrm {\alpha }_{\textrm{n}}\}\in \mathrm {S_2^{\textrm{n}}}$. Reconstruction algorithm $\textrm{SecCombine}(\vec {\mathrm {\alpha }}')$ is deterministic, taking as input $\vec {\mathrm {\alpha }}'=\{\mathrm {\alpha }'_1,\dots ,\mathrm {\alpha }'_{\textrm{t}}\}\in \mathrm {S_2^{\textrm{t}}}$ and returning the reconstructed secret $k$.

Correctness asks that for every secret $k \in \mathrm {S_1}$, every set of $\textrm{n}$ shares $\vec {\mathrm {\alpha }}$ output by $\textrm{SecShare}( k ,\textrm{t},\textrm{n})$, and every subset $\{\mathrm {\alpha }'_1,\dots ,\mathrm {\alpha }'_{\textrm{t}}\}=\vec {\mathrm {\alpha }}'\subseteq \vec {\mathrm {\alpha }}$ of size $\textrm{t}$, then $\textrm{SecCombine}(\vec {\mathrm {\alpha }}')= k$.

Definition 6

($\textrm{SSS}$ Security). A secret sharing scheme $(\textrm{SecShare},\textrm{SecCombine})$ over $\mathrm {S_1}$ is secure if for every $k , k '\in \mathrm {S_1}$, and every subset $\vec {\mathrm {\alpha }}'\in \mathrm {S_2^{\textrm{t}-1}}$, the distribution $\textrm{SecShare}( k ,\textrm{t},\textrm{n})[\vec {\mathrm {\alpha }}']$ is identical to the distribution $\textrm{SecShare}( k ',\textrm{t},\textrm{n})[\vec {\mathrm {\alpha }}']$.

The most well known secret sharing scheme is due to Shamir [37] using polynomial interpolation and is suitable for our purposes. The scheme is fully specified elsewhere [9, 37] and we refer to these sources for details. For the purposes of this paper, it is sufficient to know that Shamir’s scheme is over $\mathrm {S_1}=\mathbb {F}_q$ with prime power $q>\textrm{n}$, where shares are elements of $\mathrm {S_2^{}}=\mathbb {F}_q^2$. We choose $\mathrm {S_1}$ such that it matches our key space $\mathcal {K}$, for example $\mathrm {S_1}=\mathbb {F}_{2^{256}}$ if we have a 256-bit key space.

D OPRF Definition Relations

We now show the equivalence of our multi-server $\mathrm {PRIV\hbox {-}{x}}$ games and the single-server $\mathrm {POPRIV\hbox {-}{x}}$ games introduced by Tyagi et al. [40]. As stated earlier, our $\mathrm {PRIV\hbox {-}{2}}$ game is identical to the $\mathrm {POPRIV\hbox {-}{2}}$ game of Tyagi et al., and so we focus on showing $\mathrm {PRIV\hbox {-}{1}}\Leftrightarrow \mathrm {POPRIV\hbox {-}{1}}$.

Theorem 7

Let $\textsf{F}$ be an oblivious pseudorandom function. For any adversary $\mathcal {A}$ against the $\mathrm {PRIV\hbox {-}{1}}$ security of $\textsf{F}$, there exists an adversary $\mathcal {B}$ against the $\mathrm {POPRIV\hbox {-}{1}}$ security of $\textsf{F}$, such that

$$ {\textbf{Adv}_{\textsf{F}}^{\mathrm {PRIV\hbox {-}{1}}}}({\mathcal {A}}) \le {\textbf{Adv}_{\textsf{F}}^{\mathrm {POPRIV\hbox {-}{1}}}}({\mathcal {B}}). $$

Proof

The direct reduction is detailed in Fig. 9. $\mathcal {B}$ runs $\mathcal {A}$, and needs to respond to $\mathcal {A}$’s calls to $\textrm{Challenge}$. Note that $\mathcal {A}$’s calls to $\textrm{Challenge}$ give $( uid ,\textrm{x}_0,\textrm{x}_1)$ as input, and $\mathcal {A}$ expects $(\textrm{req}_b,\textrm{req}_{1-b})$ in response, when it is playing $\mathrm {PRIV\hbox {-}{1}}^b$. $\mathcal {B}$’s own oracle $\textrm{TRANS}_{\mathcal {B}}$ provides a more detailed response, and so $\mathcal {B}$ simply takes the $\textrm{req}_b,\textrm{req}_{1-b}$ that it receives and forwards this to $\mathcal {A}$.

Let b be the challenge bit in the experiment that $\mathcal {B}$ is playing, and let $b'$ be the bit that is output by $\mathcal {A}$. $\mathcal {B}$ receives $(\textrm{req}_b,\textrm{rep}_b,\textrm{y}_0,\textrm{req}_{1-b},\textrm{rep}_{1-b},\textrm{y}_1)$ from its own call to $\textrm{TRANS}_{\mathcal {B}}$, and thus providing $(\textrm{req}_b,\textrm{req}_{1-b})$ to $\mathcal {A}$ simulates $\mathcal {A}$’s expected environment.

$\mathcal {B}$ perfectly simulates $\mathrm {PRIV\hbox {-}{1}}^b$ for $\mathcal {A}$, since the secret key vector is correctly distributed and the responses that $\mathcal {A}$ receives to its oracles calls are exactly as it would expect. The advantage of $\mathcal {A}$ directly corresponds to the advantage of $\mathcal {B}$. This concludes the proof.

Fig. 9.

Reduction $\mathcal {B}$ for the proof of Theorem 7.

Theorem 8

Let $\textsf{F}$ be an oblivious pseudorandom function. For any adversary $\mathcal {A}$ against the $\mathrm {POPRIV\hbox {-}{1}}$ security of $\textsf{F}$, there exists an adversary $\mathcal {B}$ against the $\mathrm {PRIV\hbox {-}{1}}$ security of $\textsf{F}$, such that

$$ {\textbf{Adv}_{\textsf{F}}^{\mathrm {POPRIV\hbox {-}{1}}}}({\mathcal {A}}) \le {\textbf{Adv}_{\textsf{F}}^{\mathrm {PRIV\hbox {-}{1}}}}({\mathcal {B}}). $$

Proof

The reduction is detailed in Fig. 10.

Fig. 10.

Reduction $\mathcal {B}$ for the proof of Theorem 8.

In order to provide a sufficient response to $\mathcal {A}$, the reduction $\mathcal {B}$ must use the values $(\textrm{req}_b,\textrm{req}_{1-b})$ that it receives from $\textrm{TRANS}_{\mathcal {A}}$ and perform $\textsf{F}.\textsf{BlindEv}$ on them to acquire $(\textrm{rep}_b,\textrm{rep}_{1-b})$. Producing $\textrm{y}_0$ and $\textrm{y}_1$ is straightforward, since $\mathcal {B}$ can simply compute the OPRF evaluation with $\textrm{sk}_j$ and the input values $\textrm{x}_0$ and $\textrm{x}_1$. $\mathcal {B}$ combines the values into output $(\textrm{req}_b,\textrm{rep}_b,\textrm{y}_0,\textrm{req}_{1-b},\textrm{rep}_{1-b},\textrm{y}_1)$ and returns it to $\mathcal {A}$. The reduction perfectly simulates the $\mathrm {POPRIV\hbox {-}{1}}^b$ environment for $\mathcal {A}$. This concludes the proof.

E Security Proofs

Theorem 9

Let $\textsf{PERKS}$ be an $\textrm{n}$-out-of-$\textrm{n}$ $\textsf{DKA}$ scheme built using OPRF $\textsf{F}$ according to Fig. 6 and Fig. 7. For any adversary $\mathcal {A}$ against the $\mathrm {KIND\hbox {-}{2}}$ security of $\textsf{PERKS}$, there exist adversaries $\mathcal {B}$ and $\mathcal {C}$ against the $\mathrm {PRIV\hbox {-}{2}}$ and $\textrm{PRNG}$ security of $\textsf{F}$ respectively, such that

$$\begin{aligned} {\textbf{Adv}_{\textsf{PERKS}}^{\mathrm {KIND\hbox {-}{2}}}}({\mathcal {A},\textrm{n},\textrm{n}}) &\le \textrm{n}\cdot \left( 2\cdot {\textbf{Adv}_{\textsf{F}}^{\mathrm {PRIV\hbox {-}{2}}}}({\mathcal {B}}) + {\textbf{Adv}_{\textsf{F}}^{\textrm{PRNG}}}({\mathcal {C}}) + \frac{\textrm{q}}{|\mathcal {D}|} \right) . \end{aligned}$$

Fig. 11.

Reduction $\mathcal {B}$ for the proof of Theorem 4 and Theorem 5. Procedures $\textrm{setup}$ and $\textrm{reconstruct}$ as in Fig. 7 for Theorem 4 and as in Fig. 8 for Theorem 5.

Proof Sketch. The proof goes analogously to the proof of Theorem 4. We need to adapt the reductions as they cannot assume correctness and simply call the $\textsf{F}.\textrm{ev}$ procedure or the $\textrm{Ev}$ oracle, since the $\textrm{rep}$ values may now be maliciously formed. Therefore, the reductions now use the $\textsf{F}.\textrm{finalize}$ procedure and the $\textrm{Finalize}$ oracle in the $\mathrm {PRIV\hbox {-}{2}}$ game to compute the OPRF output value $\textrm{y}$ (or receive $\bot$). The modifications are trivial so we do not reproduce the reductions in full.

Theorem 10

Let $\textsf{PERKS}$ be an $\textrm{t}$-out-of-$\textrm{n}$ $\textsf{DKA}$ scheme built using OPRF $\textsf{F}$ according to Fig. 6 and Fig. 8 for $\textrm{t}$ such that $1\le \textrm{t}\le \textrm{n}$. For any adversary $\mathcal {A}$ against the $\mathrm {KIND\hbox {-}{2}}$ security of $\textsf{PERKS}$, there exist adversaries $\mathcal {B}$ and $\mathcal {C}$ against the $\mathrm {PRIV\hbox {-}{2}}$ and $\textrm{PRNG}$ security of $\textsf{F}$ respectively, such that

$$\begin{aligned} {\textbf{Adv}_{\textsf{PERKS}}^{\mathrm {KIND\hbox {-}{2}}}}({\mathcal {A},\textrm{t},\textrm{n}}) &\le \left( {\begin{array}{c}\textrm{n}\\ \textrm{t}-1\end{array}}\right) \cdot \left( 2\cdot {\textbf{Adv}_{\textsf{F}}^{\mathrm {PRIV\hbox {-}{2}}}}({\mathcal {B}}) + {\textbf{Adv}_{\textsf{F}}^{\textrm{PRNG}}}({\mathcal {C},\textrm{n}-\textrm{t}+1}) + \frac{\textrm{q}}{|\mathcal {D}|} \right) . \end{aligned}$$

Proof Sketch. This proof effectively applies both the adaptations made in Theorem 5 and Theorem 9.

F OPRFs and Their Variants

In the remaining sections we describe some of the properties of oblivious PRFs in the literature and explain how they can be used in our protocols. OPRFs can be verifiable or not, and independently, partially oblivious or not, meaning there are four categories of OPRF that we consider.

Verifiability. Verifiable OPRFs (VOPRFs) require the server to commit to the secret key that it uses, and allow the user to verify that the correct operation was performed by the server with this committed key (in a way that does not reveal the key to the user). Syntactically, the server includes a proof in $\textrm{rep}$ that the user can verify using a server public key $\textrm{pk}$.

Note that verifiability does not guarantee that a server uses the same key over multiple protocol runs. In order to check key consistency, the user is forced to store $\textrm{pk}$, and this value must be deterministically generated (this is the case for DH-based OPRFs where $\textrm{pk}=g^{\textrm{sk}}$). However, this storage need not be local: all users use the same $\textrm{pk}$ so it is sufficient for this value to be published somewhere.

Partial Obliviousness. In many applications for OPRFs the server needs to partition the input space to reduce the impact of active attacks, and this is often done by choosing a different key for each user identity $uid$. In practice this could be done by applying some key derivation function to $uid$ and $\textrm{sk}$ before the protocol is run (see below for a short discussion of this approach). Partially-oblivious PRFs (POPRFs) contain a (plaintext) input $\textrm{t}$ that provides automated partitioning, thus the server only needs one key for all users.

1.1 OPRF Literature

For a thorough treatment of OPRFs, see the SoK by Casacuberta et al. [16]; here we summarize the most important literature for our approach. Oblivious PRFs were first formally defined by Freedman et al. [21]. A vast array of applications has arisen for OPRFs, including oblivious transfer and private set intersection [29], password-authenticated key exchange [28], Cloudflare’s anonymous authentication mechanism Privacy Pass [18], checking compromised credentials [34, 39] and Meta’s ‘de-identified telemetry’ scheme [22].

The 2HashDH scheme by Jarecki et al. [23] (detailed in Fig. 2) is very efficient and has been suggested for use in TLS 1.3 with OPAQUE as password-based authentication, and is subject to a standardization effort [10].

There exist generic constructions of OPRFs from MPC techniques and homomorphic encryption that do not fit into the syntax in Sect. 2.2 since the communication does not follow a two-message pattern with the user sending the first message, see Section 2.4 of Casacuberta et al. [16] for a summary. These constructions are generally useful for gaining properties that are not useful in our setting such as input batching [30] for amortized efficiency gains.

POPRFs. To our knowledge, the only two (explicit) POPRFs are those by Everspaugh et al. [20] and Tyagi et al. [40], both of which are detailed in Fig. 2. The former requires a pairing which could be a hurdle in some practical applications, and the latter cannot support key rotation in a straightforward way.

Three works [17, 26, 32] obtain partial-obliviousness for 2HashDH in a generic way by applying a PRF to the server key and public input and using that value as the per-user key. In our generic construction in Fig. 6 we use a similar idea to turn any of the two non-PO, DH-based schemes in Fig. 2 into partially-oblivious variants, with the additional benefit of efficient computation of per-user public keys in the verifiable setting.

The approach in the (unpublished) work of JKR18 [26] actually works for any OPRF, and they present a non-updatable construction using 2HashDH and an updatable construction that uses HashDH, which is $\textsf{H}_2(\textsf{H}_1(\textrm{x})^\textrm{sk})$: this is not an OPRF since a user can use one interaction to obtain multiple evaluations.

Post-quantum OPRFs. Boneh et al. [7] gave two constructions of OPRFs from isogenies: a VOPRF from SIDH with a ‘one-more’ assumption and an OPRF from CSIDH. A year later, Basso et al. [4] showed that the first construction’s assumption does not hold and gave attacks on that OPRF; the second CSIDH-based scheme is unaffected by this work.

From lattices, Albrecht et al. [2] demonstrated that it is possible to build round-optimal (two messages in the online phase) VOPRFs from the Banerjee and Peikert PRF, but their protocols require large parameters and computation-heavy ZK proofs.

Kolesnikov et al. [30] sought to build multiple concurrent OPRF operations in a generic way from oblivious transfer (OT). OT can be built from post-quantum assumptions, however the PRF functionality requires 5 communication rounds and is only ‘relaxed’ (as defined by Freedman et al. [21]). Note that these special purpose OPRFs, where more than two rounds are required, do not fit the syntax in Sect. 2.2.

G Use of Existing OPRFs in $\textsf{PERKS}$

As we have mentioned in Sect. 4, the DH-based VOPRFs in Fig. 2 allow the server to store one master key and compute private and public keys for users on the fly using $uid$: this operation is specified in Fig. 6. Remember that for non-verifiable OPRFs there is no public key and thus on-the-fly computation of per-user key material just needs to run a key derivation function from the server’s (single) master key $\textrm{sk}$ and $uid$ to the same space as $\textrm{sk}$.

For non-DH VOPRFs, the DH group trick is not directly applicable, so either a similar trick using the structure of the public and secret keys needs to be found, or the server needs to store per-user key material. We regard finding such tricks in post-quantum VOPRFs as future work. The CSIDH-based scheme of Boneh et al. [7] is not defined as a VOPRF, however this would appear to be a good candidate for a VOPRF that could fit with our DH trick.

Fig. 12.

Reduction $\mathcal {C}$ for the proof of Theorem 4 and Theorem 5. Procedures $\textrm{setup}$ and $\textrm{reconstruct}$ as in Fig. 7 for Theorem 4 and as in Fig. 8 for Theorem 5. J is a set of $\textrm{t}$ indices that may not be corrupted. $\sigma$ is a bijection of the uncorrupted indices in the KIND game to the indices in the underlying PRNG game.

For key rotation, the Pythia OPRF has no ‘outer hash’ (that destroys algebraic structure) and so is eligible for simple key rotation. Note that the aforementioned HashDH scheme can provide key rotation but only if the user stores inner hash values, but this is undesirable in our setting and modelling security for this case is not trivial.

This invokes a tradeoff: the Pythia OPRF provides key rotation at a computational cost (due to the pairing operation), while 2HashDH and 3HashSDHI are fast but without key rotation. As a result, the system designer needs to judge if the ‘user initiated’ key rotation methods in Sect. 5 are viable for the system’s users, and if so 2HashDH or 3HashSDHI can be used.

Note that each of the three OPRFs in Fig. 2 are proven secure in different models, and our theorems relate to the security games of the 3HashSDHI scheme. Thus it remains to formally prove that the other two schemes do in fact meet $\mathrm {POPRIV\hbox {-}{x}}$ and $\textrm{PRNG}$ security, or by showing that the proven security properties of the other schemes—VOPRF UC functionality for 2HashDH, and one-more unpredictability and one-more PRF for Pythia—are at least as strong as $\mathrm {POPRIV\hbox {-}{x}}$ and $\textrm{PRNG}$.