the pythia prf service - usenix · usenix association 24th usenix security symposium 547 the pythia...

This paper is included in the Proceedings of the 24th USENIX Security Symposium

August 12–14, 2015 • Washington, D.C.

ISBN 978-1-931971-232

Open access to the Proceedings of the 24th USENIX Security Symposium

is sponsored by USENIX

The Pythia PRF ServiceAdam Everspaugh and Rahul Chaterjee, University of Wisconsin—Madison;

Samuel Scott, University of London; Ari Juels and Thomas Ristenpart, Cornell Tech

https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/everspaugh

USENIX Association 24th USENIX Security Symposium 547

The Pythia PRF Service

Adam Everspaugh�, Rahul Chatterjee�, Samuel Scott��, Ari Juels†, and Thomas Ristenpart‡�University of Wisconsin–Madison, {ace,rchat}@cs.wisc.edu

��Royal Holloway, University of London, [email protected]†Jacobs Institute, Cornell Tech, [email protected]

‡Cornell Tech, [email protected]

AbstractConventional cryptographic services such as

hardware-security modules and software-based key-management systems offer the ability to apply apseudorandom function (PRF) such as HMAC to inputsof a client’s choosing. These services are used, forexample, to harden stored password hashes againstoffline brute-force attacks.

We propose a modern PRF service called PYTHIA de-signed to offer a level of flexibility, security, and ease-of-deployability lacking in prior approaches. The key-stone of PYTHIA is a new cryptographic primitive calleda verifiable partially-oblivious PRF that reveals a por-tion of an input message to the service but hides therest. We give a construction that additionally supportsefficient bulk rotation of previously obtained PRF val-ues to new keys. Performance measurements show thatour construction, which relies on bilinear pairings andzero-knowledge proofs, is highly practical. We also giveaccompanying formal definitions and proofs of security.

We implement PYTHIA as a multi-tenant, scalablePRF service that can scale up to hundreds of millionsof distinct client applications on commodity systems. Inour prototype implementation, query latencies are 15 msin local-area settings and throughput is within a factorof two of a standard HTTPS server. We further reporton implementations of two applications using PYTHIA,showing how to bring its security benefits to a new en-terprise password storage system and a new brainwalletsystem for Bitcoin.

1 Introduction

Security improves in a number of settings when appli-cations can make use of a cryptographic key stored ona remote system. As an important example, considerthe compromise of enterprise password databases. Bestpractice dictates that passwords be hashed and salted be-

fore storage, but attackers can still mount highly effectivebrute-force cracking attacks against stolen databases.

Well-resourced enterprises such as Facebook [38]have therefore incorporated remote cryptographic oper-ations to harden password databases. Before a passwordis stored or verified, it is sent to a PRF service externalto the database. The PRF service applies a cryptographicfunction such as HMAC to client-selected inputs undera service-held secret key. Barring compromise of thePRF service, its use ensures that stolen password hashes(due to web server compromise) cannot be cracked usingan offline brute-force attack: an attacker must query thePRF service from a compromised server for each pass-word guess. Such online cracking attempts can be mon-itored for anomalous volumes or patterns of access andthrottled as needed.

While PRF services offer compelling security im-provements, they are not without problems. Even largeorganizations can implement them incorrectly. For ex-ample, Adobe hardened passwords using 3DES but inECB mode instead of CBC-MAC (or another secure PRFconstruction) [23], a poor choice that resulted in disclo-sure of many of its customers’ passwords after a breach.Perhaps more fundamental is that existing PRF servicesdo not offer graceful remediation if a compromise is de-tected by a client. Ideally it should be possible to cryp-tographically erase (i.e., render useless via key deletion)any PRF values previously used by the client, withoutrequiring action by end users and without affecting otherclients. In general, PRF services are so inaccessible andcumbersome today that their use is unfortunately rare.

In this paper, we present a next-generation PRF ser-vice called PYTHIA to democratize cryptographic hard-ening. PYTHIA can be deployed within an enterprise tosolve the issues mentioned above, but also as a public,multi-tenant web service suitable for use by any type oforganization or even individuals. PYTHIA offers severalsecurity features absent in today’s conventional PRF ser-vices that are critical to achieving the scaling and flexibil-

1

548 24th USENIX Security Symposium USENIX Association

ity required to simultaneously support a variety of clientsand applications. As we now explain, achieving thesefeatures necessitated innovations in both cryptographicprimitive design and system architecture.

Key features and challenges. We refer to an entity us-ing PYTHIA as a client. For example, a client might bea web server that performs password-based authentica-tion for all of its end users. Intuitively, PYTHIA allowssuch a client to query the service and obtain the PRF out-put Y = Fk(t,m) for a message m and a tweak t of theclient’s choosing under a client-specific secret key k heldby the service. Here, the tweak t is typically a uniqueidentifier for an end user (e.g., a random salt). In ourrunning password storage example, the web server storesY in a database to authenticate subsequent logins.

PYTHIA offers security features that at, first glance,sound mutually exclusive. First, PYTHIA achieves mes-sage privacy for m while requiring clients to reveal t tothe server. Message privacy ensures that the PRF ser-vice obtains no information about the message m; in ourpassword-storage example, m is a user’s password. Atthe same time, though, by revealing t to the PRF ser-vice, the service can perform fine-grained monitoring ofrelated requests: a high volume or otherwise anomalouspattern of queries on the same t would in our running ex-ample be indicative of an ongoing brute-force attack andmight trigger throttling by the PRF service.

By using a unique secret key k for each client, PYTHIAsupports individual key rotation should the value Y bestolen (or feared to be stolen). With traditional PRFservices and password storage, such key rotation is aheadache, and in many settings impractical, because itrequires transitioning stored values Y1, . . . , Yn (one foreach user account) to a new PRF key. The only way todo so previously was to have all n users re-enter or resettheir passwords. In contrast, the new primitive employedfor Fk in PYTHIA supports fast key rotation: the servercan erase k, replace it with a new key k′, and issue acompact (constant-sized) token with which the client canquickly update all of its PRF outputs. This feature alsoenables forward-security in the sense that the client canproactively rotate k without disrupting its operation.

PYTHIA provides other features as well, but we defertheir discussion to Section 2. Already, those listed abovesurface some of the challenging cryptographic tensionsthat PYTHIA resolves. For example, the most obviousprimitive on which to base PYTHIA is an oblivious PRF(OPRF) [27], which provides message privacy. But forrate-limiting, PYTHIA requires clients to reveal t, and ex-isting OPRFs cannot hide only a portion of a PRF input.Additionally, the most efficient OPRFs (c.f., [28]) are notamenable to key rotation. We discuss at length other re-

lated concepts (of which there are many) in Section 7.

Partially-oblivious PRFs. We introduce partiallyoblivious PRFs (PO-PRFs) to rectify the above ten-sion between fine-grained key management and bulk keymanagement and achieve a primitive that supports batchkey rotation. We give a PO-PRF protocol in the randomoracle model (ROM) similar to the core of the identity-based non-interactive key exchange protocol of Sakai,Ohgishi, and Kasahara [44]. This same constructionwas also considered as a left-or-right constrained PRFby Boneh and Waters [13]. That said, the functional-ity achieved by our PO-PRF is distinct from these priorworks and new security analyses are required. Despiterelying on pairings, we show that the full primitive is fasteven in our prototype implementation.

In addition to a lack of well-matched cryptographicprimitives, we find no supporting formal definitions thatcan be adapted for verifiable PO-PRFs. (Briefly, previousdefinitions and proofs for fast OPRFs rely on hashing inthe ROM before outputting a value [16, 28]; in our set-ting, hashing breaks key rotation.) We propose a new as-sumption (a one-more bilinear decisional Diffie-Hellmanassumption), give suitable security definitions, and provethe security of the core primitive in PYTHIA under thesedefinitions (in the appendix; complete results in [25]).Our new definitions and technical approaches may be ofindependent interest.

Using PYTHIA in applications. We implementPYTHIA and show that it offers highly practical per-formance on Amazon EC2 instances. Our experimentsdemonstrate that PYTHIA is practical to deploy using off-the-shelf components, with combined computation costof client and server under 12 milliseconds. A single8-core virtualized server can comfortably support over1,000 requests per second, which is already within a fac-tor of two of a standard HTTPS server in the same con-figuration. (Our PYTHIA implementation performs allcommunication over TLS.) We discuss scaling to han-dle more traffic volume in the body; it is straightforwardgiven current techniques.

We demonstrate the benefits and practicality ofPYTHIA for use in a diverse set of applications. First isour running example above: we build a new password-database system using a password “onion” that com-bines parallelized calls to PYTHIA and a conventionalkey hashing mechanism. Our onion supports PYTHIAkey rotation, hides back-end latency to PYTHIA duringlogins (which is particularly important when accessingPYTHIA as a remote third-party service), and achieveshigh security in a number of compromise scenarios.

Finally, we show that PYTHIA provides valuable fea-tures for different settings apart from enterprise pass-word storage. We implement a client that hardens a type

2


Figure 1: Diagram of PRF derivations enabled byPYTHIA. Everything inside the large box is operated bythe server, which only learns tweaks and not the shadedmessages.

of password-protected virtual-currency account called a“brainwallet” [14]; use of PYTHIA here prevents offlinebrute-force attacks of the type that have been common inBitcoin.

Our prototype implementation of PYTHIA is built withopen-source components and itself is open-source. Wehave also released Amazon EC2 images to allow com-panies, individuals, and researchers to spin-up PYTHIAinstances for experimentation.

2 Overview and Challenges

We now give a high-level overview of PYTHIA, the moti-vations for its features, what prior approaches we inves-tigated, and the threat models we assume. First we fixsome terminology and a high-level conceptual view ofwhat a PRF service would ideally provide. The serviceis provisioned with a master secret key msk. This willbe used to build a tree that represents derived sub-keysand, finally, output values. See Figure 1, which depictsan example derivation tree associated with PYTHIA aswell as which portions of the tree are held by the server(within the large box) and which are held by the client(the leaves). Keys of various kinds are denoted by cir-cles and inputs by squares.

From the msk we derive a number of ensemble keys.Each ensemble key is used by a client for a set of re-lated PRF invocations — the ensemble keys give riseto isolated PRF instances. We label each ensemble keyin the diagram by K[w]. Here w indicates a client-chosen ensemble selector. An ensemble pre-key K[w] isa large random value chosen and held by the server. To-gether, msk and K[w] are used to derive the ensemble keykw = HMAC(msk,K[w]). A table is necessary to sup-port cryptographic erasure of (or updates to) individualensemble keys, which amounts to deleting (or updating)a table entry.

Each ensemble key can be used to obtain PRF outputsof the form Fkw

(t,m) where F is a (to-be-defined) PRFkeyed by kw, and the input is split into two parts. Wecall t a tweak following [30] and m the message. Look-ing ahead t will be made public to PYTHIA while m willbe private. This is indicated by the shading of the PRFoutput boxes in the figure.

Deployment scenarios. To motivate our design choicesand security goals, we relay several envisioned deploy-ment scenarios for PYTHIA.

Enterprise deployment: A single enterprise can deployPYTHIA internally, giving query access only to other sys-tems they control. A typical setup is that PYTHIA fieldsqueries from web servers and other public-facing sys-tems that are, unfortunately, at high risk of compromise.PRF queries to PYTHIA harden values stored on thesevulnerable servers. This is particularly suited to storingcheck-values for passwords or other low-entropy authen-tication tokens, where one can store Fkw(t,m) where tis a randomly chosen, per-user identifier (a salt) and m isthe low-entropy password or authentication token. Herew can be distinct for each server using PYTHIA.

Public cloud service: A public cloud such as Ama-zon EC2, Google Compute Engine, or Microsoft Azurecan deploy PYTHIA as an internal, multi-tenant servicefor their customers. Multi-tenant here means that differ-ent customers query the same PYTHIA service, and thecloud provider manages the service, ensemble pre-keytable, etc. This enables smaller organizations to obtainthe benefits of using PYTHIA for other cloud properties(e.g., web servers running on virtual machine instances)while leaving management of PYTHIA itself to experts.

Public Internet service: One can take the public cloudservice deployment to the extreme and run PYTHIA in-stances that can be used from anywhere on the Internet.This raises additional performance concerns, as one can-not rely on fast intra-datacenter network latencies (sub-millisecond) but rather on wide-area latencies (tens ofmilliseconds). The benefit is that PYTHIA could then beused by arbitrary web clients, for example we will ex-plore this scenario in the context of hardening brainwal-lets via PYTHIA.

One could tailor a PRF service to each of these set-tings, however it is better to design a single, application-agnostic service that supports all of these settings si-multaneously. A single design permits reuse of open-source implementations; standardized, secure-by-defaultconfigurations; and simplifies the landscape of PRF ser-vices.

Security and functionality goals. Providing a singlesuitable design requires balancing a number of securityand functionality goals. The most obvious requirementsare for a service that: provides low-latency protocols

3


(i.e., single round-trip and amenable for implementationas simple web interfaces); scales to hundreds of millionsof ensembles; and produces outputs indistinguishablefrom random values even when adversaries can query theservice. To this list of basic requirements we add:

• Message privacy: The PRF service must learn noth-ing about m. Message privacy supports clients thatrequire sensitive values such as passwords to remainprivate even if the service is compromised, or topromote psychological acceptability in the case thata separate organization (e.g., a cloud provider) man-ages the service.

• Tweak visibility: The server must learn tweak t topermit fine-grained rate-limiting of requests.1 In thepassword storage example, a distinct tweak is as-signed to each user account, allowing the service todetect and limit guessing attempts against individ-ual user accounts.

• Verifiability: A client must be able to verify thata PRF service has correctly computed Fkw for aensemble selector w and tweak/message pair t,m.This ensures, after first use of an ensemble by aclient, that a subsequently compromised server can-not surreptitiously reply to PRF queries with incor-rect values.2

• Client-requested ensemble key rotations: A clientmust be permitted to request a rotation of its en-semble pre-key K[w] to a new one K[w]. The servermust be able to provide an update token ∆w to rollforward PRF outputs under K[w] to become PRFoutputs under K[w], meaning that the PRF is key-updatable with respect to ensemble keys. Addition-ally, ∆w must be compact, i.e., constant in the num-ber of PRF invocations already performed under w.Clients can mandate that rotation requests be au-thenticated (to prevent malicious key deletion). Aclient must additionally be able to transfer an en-semble from one selector w to another selector w′.

• Master secret rotations: The server must be able torotate the master secret key msk with minimal im-pact on clients. Specifically, the PRF must be key-updatable with respect to the master secret key mskso that PRF outputs under msk can be rolled for-ward to a new master secret msk. When such arotation occurs, the server must provide a compactupdate token δw for each ensemble w.

1In principle, the server need only be able to link requests involv-ing the same t, not learn t. Explicit presentation of t is the simplestmechanism that satisfies this requirement.

2This matters, for example, if an attacker compromises the commu-nication channel but not the server’s secrets (msk and K[w]). Such anattacker must not be able to convince the client that arbitrary or incor-rect values are correct.

• Forward security: Rotation of an ensemble key ormaster secret key results in complete erasure of theold key and the update token.

Two sets of challenges arise in designing PYTHIA.The first is cryptographic. It turns out that the combi-nation of requirements above are not satisfied by any ex-isting protocols we could find. Ultimately we realizeda new type of cryptographic primitive was needed thatproves to be a slight variant of oblivious PRFs and blindsignatures. We discuss the new primitive, and our effi-cient protocol realizing it, in the next section. The secondset of challenges surrounds building a full-featured ser-vice that provides the core cryptographic protocol, whichwe treat in Section 4.

3 Partially-oblivious PRFs

We introduce the notion of a (verifiable) partially-oblivious PRF. This is a two-party protocol that allowsthe secure computation of Fkw

(t,m), where F is a PRFwith server-held key kw and t,m are the input values.The client can verify the correctness of Fkw

(t,m) rel-ative to a public key associated to kw. Following ourterminology, t is a tweak and m is a message. We saythe PRF is partially oblivious because t is revealed to theserver, but m is hidden from the server.

Partially oblivious PRFs are closely related to, but dis-tinct from, a number of existing primitives. A standardoblivious PRF [27], or its verifiable version [28], wouldhide both t and m, but masking both prevents granularrate limiting by the server. Partially blind signatures [1]allow a client to obtain a signature on a similarly par-tially blinded input, but these signatures are randomizedand the analysis is only for unforgeability which is insuf-ficient for security in all of our applications.

We provide more comparisons with related work inSection 7 and a formal definition of the new primitive inAppendix B. Here we will present the protocol that suf-fices for PYTHIA. It uses an admissible bilinear pairinge : G1 × G2 → GT over groups G1,G2,GT of primeorder q, and a pair of hash functions H1 : {0, 1}∗ → G1

and H2 : {0, 1}∗ → G2 (that we will model as ran-dom oracles). More details on pairings are provided inAppendix B. A secret key kw is an element of p. ThePRF F that the protocol computes is:

Fkw(t,m) = e

(H1(t), H2(m)

)kw.

This construction coincides with the Sakai, Ohgishi, andKasahara [44] construction for non-interactive identity-based key exchange, where t and m would be differentidentities and kw a secret held by a trusted key authority.Likewise, this construction is equivalent to the left-or-right constrained PRF of Boneh and Waters [13]. The

4


PRF-Cl (w, t,m)PRF-Srv (msk)

r ←$ q

x ← H2(m)r

w, t, x�x ← e(H1(t), x)

kw ← HMAC(msk,K[w])

pw ← gkw

y ← xkw

pw, y, π�π ←$ ZKP(DLg(pw) = DLx(y))

If pw matches &π verifies then

Ret y1/r

Else Ret ⊥

Figure 2: The partially-oblivious PRF protocol usedin PYTHIA. The value π is a non-interactive zero-knowledge proof that the indicated discrete logs match.The client also checks that pw matches ones seen previ-ously when using selector w.

contexts of these prior works are distinct from ours andour analyses will necessarily be different, but we notethat all three settings similarly exploit the algebraic struc-ture of the bilinear pairing. See Section 7 for further dis-cussion of related work.

The client-server protocol that computes Fkw(t,m) ina partially-oblivious manner is given in Figure 2. Therewe let g be a generator of G1. We now explain how theprotocol achieves our requirements described in the lastsection.

Blinding the message: In our protocol, the clientblinds the message m, hiding it from the server, by rais-ing it to a randomly selected exponent r←$ q . Ase(H1(t), H2(m)r

)= e

(H1(t), H2(m)

)r, the client can

unblind the output y of PRF-Srv by raising it to 1/r. Thisprotocol hides m unconditionally, as H2(m)r is a uni-formly random element of G2.

Verifiability: The protocol enables a client to verify thatthe output of PRF-Srv is correct, assuming the client haspreviously stored pw. The server accompanies the outputy of the PRF with a zero-knowledge proof π of correct-ness.

Specifically, for a public key pw = gkw , where gis a generator of G1, the server proves DLg(pw) =DLx(y). Standard techniques (see, e.g., Camenisch andStadler [17]) permit efficient ZK proofs of this kind in therandom oracle model. 3 The notable computational costsfor the server are one pairing and one exponentiation in

3Some details: The prover picks v ←$ q and then computes t1 =gv and t2 = xv and c ← H3(g, pw, x, y, t1, t2). Let u = v − c ·k.The proof is π = (c, u). The verifier computes t′1 = gu · pcw andt′2 = xuyc. It outputs true if c = H3(g, pw, x, y, t′1, t

′2).

GT ; for the client, one pairing and two exponentiationsin GT . 4

Efficient key updates: The server can quickly andeasily update the key kw for a given ensemble selec-tor w by replacing the table entry s = K[w] with anew, randomly selected value s′, thereby changing kw =HMAC(msk, s) to k′w = HMAC(msk, s′). It can thentransmit to the client an update token of the form ∆w =k′w/kw ∈ q .

The client can update any stored PRF valueFkw(t,m) = e

(H1(t), H2(m)

)kw by raising it to ∆w;it is easy to see that Fkw

(t,m)∆w = Fk′w(t,m).

The server can use the same mechanism to updatemsk, which requires generating a new update token foreach w and pushing these tokens to clients as needed.

Unblinded variants. For deployments where oblivious-ness of messages is unnecessary, we can use a faster, un-blinded variant of the PYTHIA protocol that dispenseswith pairings. The only changes are that the client sendsm to the server, there is no unblinding of the server’s re-sponse, and, instead of computing

x ← e(H1(t), x)

the server computes

x ← H3(t ‖m) .

All group operations in this unblinded variant are over astandard elliptic curve group G = 〈g〉 of order q and weuse a hash function H3 : {0, 1}∗ → G.

An alternative unblinded construction would be tohave the server apply the Boneh-Lynn-Shacham shortsignatures [12] to the client-submitted t ‖m; verificationof correctness can be done using the signature verifica-tion routine, and we can thereby avoid ZKPs. This BLSvariant may save a small amount of bandwidth.

These unblinded variants provide the same services(verifiability and efficient key updates) and security withthe obvious exception of the secrecy of the message m.In some deployment contexts an unblinded protocol maybe sufficient, for example when the client can maintainstate and submit a salted hash m instead of m directly.In this context, the salt should be held as a secret on theclient and never sent to the server.

4 The PYTHIA Service Design

Figure 3 gives the high-level API exposed by PYTHIAto a client. We now describe its functions in terms ofthe lifecycle of an ensemble key. We assume a securityparameter n specifying symmetric key lengths; a typicalchoice would be n = 128.

4The client’s pairing can be pre-computed while waiting for theserver’s reply.

5


Command DescriptionInit(w [, options]) Create table entry K[w] (for ensemble

key kw)

Eval(w, t,m) Return PRF output Fkw (t,m)

Reset(w, authtoken) Update K[w] (and thus kw); returnupdate token ∆w

GetAuth(w) Send one-time authentication tokenauthtoken to client

Figure 3: The basic PYTHIA API.

We defer to later sections the underlying client-serverprotocols and to Appendix A details on key lifecyclemanagement options, additional API calls for token man-agement and ensemble transfer, and a discussion of mas-ter secret key rotation.

Ensemble initialization. To begin using the PYTHIAservice, a client creates an ensemble key for selector wby invoking Init(w [, options]). PYTHIA generates afresh, random table entry K[w]. Recall that ensemblekey kw = HMAC(msk,K[w]). So Init creates kw asa byproduct.

Ideally, w should be an unguessable byte string. (Aneasily guessed one may allow attackers to squat on a keyselector, thereby mounting a denial-of-service (DoS) at-tack.) For some applications, as we explain below, thisisn’t always possible. If an ensemble key for w alreadyexists, then the PYTHIA service returns an error to theclient. Otherwise, the client receives a message signify-ing that initialization is successful.Init includes a number of options we detail in Ap-

pendix A.

PRF evaluation. To obtain a PRF value, a client canperform an evaluation query Eval(w, t,m), which re-turns Fkw

(t,m). Here t is a tweak and m is a mes-sage. To compute the PRF output, the client and serverperform a one-round cryptographic protocol (meaning asingle message from client to server, and one messageback). We present details in Section 3, but remind thereader that t is visible to the server in the client-serverprotocol invoked by Eval, while m is blinded.

The server rate-limits requests based on the tweak t,and can also raise an alert if the rate limit is exceeded.We give example rate limiting policies in Section 5.

Ensemble-key reset. A client can request that an en-semble key kw be reset by invoking Reset(w). This resetis accomplished by overwriting K[w] with a fresh, ran-dom value. The name service returns a compact (e.g.,256-bit) update token ∆w that the client may use to up-date all PRF outputs for the ensemble. It stores this to-ken locally, encrypted under a public key specified by theclient, as explained below.

Note that reset results in erasure of the old value of kw.Thus a client that wishes to delete an ensemble key kwpermanently at the end of its lifecycle can do so with aReset call.Reset is an authenticated call, and thus requires the

following capability.

Authentication. To authenticate itself for API calls, theclient must first invoke GetAuth, which has the servertransmit an (encrypted) authentication token authtokento the client out-of-band. The token expires after a pe-riod of time determined by a configuration parameter inPYTHIA. Our current implementation uses e-mail forthis, see Appendix A for more details. Of course, insome deployments one may want authentication to beperformed in other ways, such as tokens dispensed byadministrators (for enterprise settings) or simply givenout on a first-come-first-serve basis for each ensembleidentifier (for public Internet services).

4.1 Implementation

We implemented a prototype PYTHIA PRF service asa web application accessed over HTTPS. All requestsare first handled by an nginx web server with uWsgi asthe application server gateway that relays requests to aDjango back-end. The PRF-Srv functionality is imple-mented as a Django module written in Python. Storagefor the server’s key table and rate-limiting information isdone in MongoDB.

We use the Relic cryptographic library [2] (writtenin C) with our own Python wrapper. We use Barreto-Naehrig 254-bit prime order curves (BN-254) [4]. Thesecurves provide approximately 128-bits of security.

In our experiments the service is run on a single (vir-tual) machine, but our software stack permits compo-nents (web server, application sever, database) to be dis-tributed among multiple machines with updates to con-figuration files.

For the purpose of comparison, we implemented threevariants of the PYTHIA service. The first two are the un-blinded protocols described in Section 3. In these twoschemes, the client sends m in the clear (possibly hashedwith a secret salt value first) and the server replies withy = H1(t ‖m)k. In the first scheme, denoted UNB,the server provides p = gk1 and a zero-knowledge proofwhere g1 is a generator of G1. The second scheme, de-noted BLS, uses a BLS signature for verification. Theserver provides p = gk2 where g2 is a generator of G2 andthe client verifies the response by computing and com-paring the values: e(y, g2) = e(H1(t ‖m), p).

Our partially-oblivious scheme is denoted PO.

For the evaluation below we use a Python client im-plementing PRF-Cl for all three schemes using the same

6


Time (µs)Group Group Op Exp HashingG1 5.7 175 77G2 6.7 572 210GT 9.8 1145 –

pairing operation (e) takes 1005 µs

Figure 4: Time taken by each operation in BN-254groups. Hashing times are for 64-byte inputs.

libraries indicated above for the server and httplib2 toperform HTTPS requests.

4.2 Performance

For performance and scalability evaluation we hostedour PYTHIA server implementation on Amazon’s ElasticCompute Cloud (EC2) using a c4.xlarge instance whichprovides 8 virtual CPUs (Intel Xeon third generation,2.9GHz), 15 GB of main memory, and solid state storage.The web server, nginx, was configured with basic set-tings recommended for production deployment includingone worker process per CPU.

Latency. We measured client query latency for eachprotocol using two clients: one within the same AmazonWeb Service (AWS) availability zone (also c4.xlarge)and one hosted at the University of Wisconsin–Madisonwith an Intel Core i7 CPU (3.4 GHz). We refer to the firstas the LAN (local-area network) setting and the secondas the WAN (wide-area network) setting. In the LAN set-tings we used the AWS internal IP address. All querieswere made over TLS and measurements include the timerequired for clients to blind messages and unblind results(PO), as well as verify proofs provided by the server (un-less indicated otherwise). All machines used for evalua-tion were running Ubuntu 14.04.

Microbenchmarks for group operations appear inFigure 4 and Figure 5 shows the timing of individual op-erations that comprise a single PRF evaluation. All re-sults are mean values computed over 10,000 operations.These values were captured on an EC2 c4.xlarge instanceusing the Python profiling library line profiler. The mostexpensive operations, by a large margin, are exponentia-tion in Gt and the pairing operation. By extension, POsign, prove, and verify operations become expensive.

We measured latencies averaged over 1,000 PRF re-quests (with 100 warmup requests) for each scheme andthe results appear in Figure 6. Computation time domi-nates in the LAN setting due to the almost negligible net-work latency. The WAN case with cold connections (noHTTP KeepAlive) pays a performance penalty due to thefour round-trips required to set up a new TCP and TLSconnection. While even 400 ms latencies are not pro-hibitive in our applications, straightforward engineering

Server Op Time (ms)Table 1.2

Rate-limit 0.9UNB BLS PO

Sign 0.3 0.3 1.5Prove 0.5 0.3 2.5

Client Op UNB BLS POBlind - - 0.3

Unblind - - 1.2Verify 0.9 2.0 4.0

Figure 5: Computation time for major operations toperform a PRF evaluation. Table retrieves K[w] fromdatabase; Rate-limit updates rate-limiting record indatabase; and Sign generates the PRF output;

Latency (ms)LAN WAN

Scheme Cold Hot No π Cold Hot No πUNB 7.0 3.8 2.4 389 82 80BLS 7.9 4.9 2.4 392 85 80

PO 14.9 11.8 5.2 403 96 84RTT ping 0.1 82

Figure 6: Average latency to complete a PRF-Cl withclient-server communication over HTTPS. LAN: clientand server in the same EC2 availability zone. WAN:server in EC2 US-West (California) and client in Madi-son, WI. Hot connections made with HTTP KeepAliveenabled; cold connections with KeepAlive disabled. Noπ: KeepAlive enabled; prove and verify computationsare skipped.

improvements would vastly improve WAN timing: us-ing TLS session resumption, using lower-latency secureprotocol like QUIC [43], or even switching to a customUDP protocol (for an example one for oblivious PRFs,see [5]).

Throughput. We used the distributed load testing toolautobench to measure maximum throughput for eachscheme. We compare to a static page containing a typi-cal PRF response served over HTTPS as a baseline. Weused two clients in the same AWS region as the server.All connections were cold: no TLS session resumptionor HTTP KeepAlive. The maximum throughput for astatic page is 2,200 connections per second (cps); UNBand BLS 1,400 cps; and PO 1,350 cps. Thus our PYTHIAimplementation can handle a large number of clients ona single EC2 instance. If needed, the implementation canbe scaled with standard techniques (e.g., a larger numberof web servers and application servers on the front-endwith a distributed key-value store on the back-end).

Storage. Our implementation stores all ensemble pre-key table (K) entries and rate-limiting information inMongoDB. A table entry is two 32 byte values: a SHA-

7


256 hash of the ensemble selector w and its associatedvalue K[w]. In MongoDB the average storage size is 195bytes per entry (measured as the average of 100K en-tries), including database overheads and indexes. Thisimplementation scales easily to 100 M clients with under20 GB of storage.

To rate-limit queries, our implementation stores tweakvalues along with a counter and a timestamp (to ex-pire old entries) in MongoDB. Tweak values are alsohashed using SHA-256 which ensures entries are of con-stant length. In our implementation each distinct tweakrequires an average of 144 bytes per entry (includingoverheads and indexes). Note however that rate limit-ing entries are purged periodically as counts are onlyrequired for one rate-limiting period. Our implementa-tion imposes rate-limits at hour granularity. Assuming amaximum throughput of 2,000 requests per second, rate-limiting storage never exceeds 1 GB.

All told, with only 20 GB stored data, PYTHIA canserve over 100 M clients and perform rate-limiting athour granularity. Thus fielding a database for PYTHIAcan be accomplished on commodity hardware.

5 Password Onions

Web servers and other systems frequently store pass-words in hashed form. A password onion is the result ofadditionally invoking a PRF service to harden the hash.In currently suggested onions, one sequentially combineslocal hashing and application of the PRF service.

We now present a service that we have implementedon top of PYTHIA for managing password onions. First,we describe the limitations of contemporary systemsas exemplified by a recently disclosed architecture em-ployed by Facebook [39]. Then we show how ourpassword-onion system, which was easily engineered ontop of PYTHIA, can address these limitations.

In what follows, we use the term “client” or “webserver” to denote the server performing authenticationand storing derived values from passwords and “PRFserver” to denote the PYTHIA service.

5.1 Facebook password onionAn example of a contemporary system, used by Face-book, is given in Figure 7.5 Their PRF service appliesHMAC using a service-held secret and returns the result.In this architecture, an adversary that compromises theweb server and the password hashes it stores must still

5This figure is of “archaeological” interest. It appears that vul-nerabilities in MD5 led to the addition of a layer of processing un-der SHA-1; when vulnerabilities were found in SHA-1, Facebook thenadded layers of SHA-256. As we explain later, full-blown replacementof MD5 and SHA-1 with SHA-256 was not easily accomplished.

PW-Onion(pw)

h1 ← MD5(pw)

sa←$ {0, 1}160h2 ← HMAC[SHA-1](h1, sa)

h3 ← PRF-Cl(h2) = HMAC[SHA-256](h2,msk)

h4 ← scrypt(h3, sa)

h5 ← HMAC[SHA-256](h4)

Ret (sa, h5)

Figure 7: The Facebook password onion. PRF-Cl(h2)invokes the Facebook PRF service HMAC[SHA-256](h2,Ks) with PRF-service secret key Ks.

mount an online attack against the PRF service to com-promise accounts. This is a big advance on the hashing-only practices that are commonly used.

The Facebook architecture nevertheless has someshortcomings. It is easy to see from Figure 7 that Face-book’s system, like most contemporary PRF services,lacks several important features present in PYTHIA. Oneis message privacy: the Facebook PRF service appliesHMAC to h2. This is the salted hash of the password,and so learning the salt as well as compromising the PRFservice suffices to re-enable offline brute-force attacks.This threat is avoided by PYTHIA due to blinding.

Another feature is batch key updates. In fact, the Face-book PRF service doesn’t permit autonomous key up-dates at all, in the sense of an update to msk that can bepropagated into PRF output updates. Should the client(password database) be compromised, the only way toreconstitute a hash in an existing password onion is towait until a user logs in and furnishes pw. It is notclear whether the Facebook PRF service performs granu-lar rate-limiting, although no such capability is indicatedin [38]. PYTHIA, as we shall see, addresses all of theseissues by design in our password onion system.

The Facebook onion also presents a subtle perfor-mance issue. By applying cryptographic primitives se-rially, the time to hash a password equals the time forlocal computations, call it tlocal, plus the time for theround-trip PRF service call, call it tprf . An attacker thatcompromises the web service and PRF service incurs nonetwork latency, and thus may gain a considerable ad-vantage in guessing time over an honest web server. Inour PYTHIA-based password onion service, we addressthis issue by observing that it is possible to avoid seri-alization of key derivation functions on the web serverand the PRF service call. That is, we introduce in ourPYTHIA-based service the idea of parallelizable pass-word onions.

8


UpParOnion(w, sa, pw)

z ← PBKDF(pw, sa)

u ← PRF-Cl(w, sa, pw)

h ← uz

Ret (h, sa)

Figure 8: An updatable, parallelizable password onion.PRF-Cl returns elements of a group G. The value w is aunique PRF-service identifier for the web server (e.g., arandom 256-bit string) and sa is a random per-user saltvalue.

5.2 PYTHIA password onionThe onion algorithm we construct for PYTHIA is shownin Figure 8. For PYTHIA, the output of PRF-Cl isan element of a group GT . To use this service, aweb server stores (h, sa) upon password registration;it verifies a proffered password pw′ by checking thatUpParOnion(w, sa, pw′) = h. Written out we have that:

h = uz = e(H1(sa), H2(pw))kwz.

This design ensures that the key update functions in thePYTHIA API may be used to update onions as well. Forexample, to update an ensemble key kw to k′w, the servicecomputes and furnishes to the web server an update token∆w = k′w/kw. The web server may compute h∆w foreach stored value h.

Parallelization. Password verification here is paral-lelizable in the sense that z and u may be computed in-dependently and then combined. Such parallel imple-mentation of the onion achieves a password verificationlatency of max{tlocal, tprf} (plus a single exponentia-tion), as opposed to tlocal + tprf in a serialized imple-mentation.

A web server generally aims to achieve a verificationlatency equal to some latency target T that is high enoughto slow offline brute-force attacks, but low enough not toburden users. For a parallelized onion a web server canmeet its latency target by setting tlocal, tprf ≈ T . At thesame time an offline attacker that has compromised theweb server and PYTHIA must perform about tlocal+tF >T work to check a single password guess, where tF isthe computation time of Fkw (i.e., tprf minus networklatency). An attacker can parallelize, but her total workstill goes up relative to the serial onion approach for thesame latency target T .

We estimate the security improvement of parallelonions over serial onions using our benchmarks fromSection 4.2. We fix a login latency budget of T =300ms.6 The latency costs for a PYTHIA query with

6This is the default setting for Python’s bcrypt and scrypt modules,though all PBDKFs are tunable so one can choose T to be any valuedesired.

hot connections are 12 ms (LAN) and 96 ms (WAN). Ifone performs computations serially with a fixed T thenPBKDF computations need to be reduced by 4% (LAN)and 32% (WAN) compared to the parallel approach. Inthe event that the PYTHIA server and password databaseare compromised, the serial onion enables speedup of of-fline dictionary attacks by the same percentages.

Rate limiting and logging. The transparency of tweaksenables the PYTHIA PRF service in this setting to executeany of a wide range of rate-limiting policies with per-account visibility (in contrast to what may be in Face-book an account-blind PRF service). As an exampledemonstrating the flexibility of our architecture, in ourimplementation PYTHIA performs a tiered rate-limiting:for a given account (t), it limits queries to at most 10 perhour per account, and at most 300 per month. (In ex-pectation, guessing a random 4-digit PIN would require1.4 years under this policy.) It logs violations of thesethresholds. In a production environment, it could alsosend alerts to security administrators.

We emphasize that a wide range of other rate-limitingpolicies is possible. We also point out that PYTHIA’s ratelimiting supplements that normally implemented at theweb server for remote login requests. PYTHIA performsrate limiting and may issue alerts even if the web serveris compromised.

Key update. The key update calls in the PYTHIA API,and the ability to rotate either kw or msk efficiently,propagates up to the password onion service. Key up-dates instantly invalidate the web server’s existing pass-word database—a useful capability in case of compro-mise. A compromised database becomes useless to anattacker attempting to recover passwords, even with theability to query PYTHIA. Using a key update token, theweb server can then recover from compromise by re-freshing its database.

We created a client simulator with MongoDB andthe mongoengine Python module. With this we bench-marked key updates with 100,000 database entries. Theclient requested a key update from PYTHIA, received theupdate token ∆w, and updated each database entry. Thecomplete update required less than 1 ms per entry, andterminated in less than 97 seconds for all 100,000 en-tries. For a larger database we assume updates scale lin-early, and so an update for 1 million users completes inunder 17 minutes.

The web server need not need lock the database to per-form updates; it can execute them in parallel with normallogin operations. Doing so does require additional ver-sioning information for each entry to indicate the versionof kw (in the simplest form, whether or not it has receivedthe latest update).

9


6 Hardened Brainwallets

Brainwallets are a common but dangerous way to se-cure accounts in the popular cryptocurrency Bitcoin, aswell as in less popular cryptocurrencies such as Litecoin.Here we describe how the PYTHIA service can be useddirectly as a means to harden brainwallets. This appli-cation showcases the ease with which a wide variety ofapplications can be engineered around PYTHIA.

How brainwallets work. Every Bitcoin account has anassociated private / public key pair (sk, pk). The privatekey sk is used to produce digital (ECDSA) signaturesthat authorize payments from the account. The publickey pk permits verification of these signatures. It alsoacts as an account identifier; a Bitcoin address is derivedby hashing pk (under SHA-256 and RIPEMD-160) andencoding it (in base 58, with a check value).

Knowledge of the private key sk equates with controlof the account. If a user loses a private key, she thereforeloses control over her account. For example, if a high en-tropy key sk is stored exclusively on a device such as amobile phone or laptop, and the device is seized or physi-cally destroyed, the account assets become irrecoverable.

Brainwallets offer an attractive remedy for such phys-ical risks of key loss. A brainwallet is simply a passwordor passphrase P memorized by a Bitcoin account holder.The private key sk is generated directly from P . Thusthe user’s memory serves as the only instrument neededto authorize access to the account.

In more detail, the passphrase is typically hashed usingSHA-256 to obtain a 256-bit string sk = SHA-256(P ).Bitcoin employs ECDSA signatures on the secp256k1elliptic curve; with high probability (≈ 1 − 2−126), skis less than the group order, and a valid ECDSA pri-vate key. (Some websites employ stronger key derivationfunctions. For example, WrapWallet by keybase.io [29]derives sk from an XOR of each of PBKDF2 and scryptapplied to P and permits use of a user-supplied salt.)

Since a brainwallet employs only P as a secret, anddoes not necessarily use any additional security mea-sures, an attacker that guesses P can seize control of auser’s account. As account addresses are posted publiclyin the Bitcoin system (in the “blockchain”), an attackercan easily confirm a correct guess. Brainwallets are thusvulnerable to brute-force, offline guessing attacks. Nu-merous incidents have come to light showing that brain-wallet cracking is pandemic [14].7

7At one point, rumor had it that cracking brainwallets was moreprofitable than “mining,”, the basic process of generating fresh Bit-coins.

6.1 A PYTHIA-hardened brainwallet

PYTHIA offers a simple, powerful means of protectingbrainwallets against offline attack. Hardening P in thesame manner as an ordinary password yields a strong keyP that can serve in lieu of P to derive sk.

To use PYTHIA, a user chooses a unique identifier id,e.g., her e-mail address, an account identifier acct, and apassphrase P . The identifier acct might be used to distin-guish among Bitcoin accounts for users who wish to usethe same password for multiple wallets. The client thensends (w = id, t = id ‖ acct,m = P ) to the PYTHIAservice to obtain the hardened value Fkw(t,m) = P .Here, id is used both as an account identifier and as partof the salt. Message privacy in PYTHIA ensures that theservice learns nothing about P . Then P is hashed withSHA-256 to yield sk. The corresponding public keypk and address are generated in the standard way fromsk [7].

PYTHIA forces a would-be brainwallet attacker tomount an online attack to compromise an account. Notonly is an online attack much slower, but it may be rate-limited by PYTHIA and detected and flagged. As thePYTHIA service derives P using a user-specific key, itadditionally prevents an attacker from mounting a dictio-nary attack against multiple accounts. While in the con-ventional brainwallet setting, two users who make useof the same secret P will end up controlling the sameaccount, PYTHIA ensures that the same password P pro-duces distinct per-user key pairs.

Should an attacker compromise the PYTHIA serviceand steal msk and K, the attacker must still perform anoffline brute-force attack against the user’s brainwallet.So in the worst case, a user obtains security with PYTHIAat least as good as without it.

Additional security issues. A few subtle security issuesdeserve brief discussion:

• Stronger KDFs: To protect against brute-forceattack in the event of PYTHIA compromise,a resource-intensive key-derivation function maybe desirable, as is normally used in passworddatabases. This can be achieved by replacing theSHA-256 hash of P above with an appropriate KDFcomputation, or alternatively using an onion ap-proach described in Section 5.

• Denial-of-service: By performing rate-limiting,PYTHIA creates the risk of targeted denial-of-service attacks against Bitcoin users. As Bitcoinis pseudonymous, use of an e-mail address as aPYTHIA key-selector suffices to prevent such at-tacks against users based on their Bitcoin addressesalone. Users also have the option, of course, of us-ing a semi-secret id. A general DoS attack against

10


the PYTHIA service is also possible, but of similarconcern for Bitcoin itself [8].

• Key rotation: Rotation of an ensemble key kw (orthe master key msk) induces a new value of P andthus a new (sk, pk) pair and account. A client canhandle such rotations in the naıve way: transferfunds from the old address to the new one.

• Catastrophic failure of PYTHIA: If a PYTHIA ser-vice fails catastrophically, e.g., msk or K is lost,then in a typical setting, it is possible simply toreset users’ passwords. In the brainwallet case,the result would be loss of virtual-currency assetsprotected by the server—a familiar event for Bit-coin users [35]. This problem can be avoided,for instance, using a threshold implementation ofPYTHIA, as mentioned in Section 6.2 or storing skin a secure, offline manner like a safe-deposit boxfor disaster recovery.

6.2 Threshold SecurityIn order to gain both redundancy and security, we givea threshold scheme that can be used with a number ofPythia servers to protect a secret under a single pass-word. This scheme uses Shamir’s secret sharing thresh-old scheme [45] and gives (k, n) threshold security. Thatis, initially, n Pythia servers are contacted and used toprotect a secret s, and then any k servers can be used torecover s and any adversary that has compromised fewerthan k Pythia servers learns no information about s.

Preparation. The client chooses an ensemble key se-lector w, tweak t, password P , and contacts n Pythiaservers to compute qi = PRF-Cli(w, t, P ) mod p for0 < i ≤ n. The client selects a random polynomialof degree k − 1 with coefficients from ∗

p where p isa suitably large prime: f(x) =

∑k−1j=0 x

jaj . Let thesecret s = a0. Next the client computes the vectorΦ = (φ1, ..., φn) where φi = f(i) − qi. The clientdurably stores the value Φ, but does not need to protectit (it’s not secret). The client also stores public keys pifrom each Pythia server to validate proofs when issuingfuture queries.

Recovery. The client can reconstruct s if she has Φ byquerying any k Pythia servers giving k values qi. Theseqi values can be applied to the corresponding Φ valuesto retrieve k distinct points that lie on the curve f(x).With k points on a degree k − 1 curve, the client canuse interpolation to recover the unique polynomial f(x),which includes the curve’s intercept a0 = s.

Security. If an adversary is given Φ, w, t, the publickeys pi, a ciphertext based on s, and the secrets fromm < k Pythia servers, the adversary has no information

that will permit her to verify password guesses offline.Compared to [45], this scheme reduces the problem ofstoring n secrets to having access to n secure OPRFs anddurable (but non-secret) storage of the values Φ and pub-lic keys pi.

Verification. Verification of server responses occurswithin the Pythia protocol. If a server is detected to bedishonest (or goes out of service), it can be easily re-placed by the client without changing the secret s. To re-place a Pythia server that is suspected to be compromisedor detected as dishonest, the client reconstructs the secrets using any k servers, executes Reset operations on allremaining servers: this effects a cryptographic erasureon the values Φ and f(x). The client then selects a new,random polynomial, keeping a0 fixed, and generates andstores an updated Φ′ that maps to the new polynomial.

7 Related Work

We investigated a number of designs based on exist-ing cryptographic primitives in the course of our work,though as mentioned none satisfied all of our designgoals. Conventional PRFs built from block ciphers orhash functions fail to offer message privacy or key rota-tion. Consider instead the construction H(t ‖m)kw forH : {0, 1}∗ → G a cryptographic hash function map-ping onto a group G. This was shown secure as a con-ventional PRF by Naor, Pinkas, and Reingold assum-ing decisional Diffie-Hellman (DDH) is hard in G andwhen modeling H as a random oracle [40]. It supportskey rotations (in fact it is key-homomorphic [11]) andverifiability can be handled using non-interactive zero-knowledge proofs (ZKP) as in PYTHIA. But this ap-proach fails to provide message privacy if we submit botht and m to the server and have it compute the full hash.

One can achieve message-hiding by using blinding:have the client submit X = H(t ‖m)r for randomr ∈ |G| and the server reply with Xkw as well as a ZKPproving this was done correctly. The resulting schemeis originally due to Chaum and Pedersen [19], and sug-gested for use by Ford and Kaliski [26] in the contextof threshold password-authenticated secret sharing (seealso [3, 15, 20, 34]). There an end user interacts withone or more blind signature servers to derive a secret au-thentication token. If G comes equipped with a bilin-ear pairing, one can dispense with ZKPs. The resultingscheme is Boldyreva’s blinded version [10] of BLS sig-natures [12]. However, neither approach provides gran-ular rate limiting when blinding is used: the tweak t ishidden from the server. Even if the client sends t as well,the server cannot verify that it matches the one used tocompute X and attackers can thereby bypass rate limits.

To fix this, one might use Ford-Kaliski with a sep-

11


arate secret key for each tweak. This would result inhaving a different key for each unique w, t pair. Mes-sage privacy is maintained by the blinding, and queryingw, t,H(t′ ‖m)r for t �= t′ does not help an attacker cir-cumvent per-tweak rate limiting. But now the server-sidestorage grows in the number of unique w, t pairs, a clientusing a single ensemble w must now track N public keyswhen they use the service for N different tweaks, andkey rotation requires N interactions with the PRF serverto get N separate update tokens (one per unique tweakfor which a PRF output is stored). When N is large andthe number of ensembles w is small as in our passwordstorage application, these inefficiencies add significantoverheads.

Another issue with the above suggestions is that theirsecurity was only previously analyzed in the context ofone-more unforgeability [42] as targeted by blind signa-tures [18] and partially blind signatures [1]. (Some wereanalyzed as conventional PRFs, but that is in a modelwhere adversaries do not get access to a blinded serveroracle.) The password onion application requires morethan unforgeability because message privacy is needed.(A signature could be unforgeable but include the en-tire message in its signature, and this would obviate thebenefits of a PRF service for most applications.) Theseschemes, however, can be proven to be one-more PRFs,the notion we introduce, under suitable one-more DDHstyle assumptions using the same proof techniques foundin Appendix B.

Fully oblivious PRFs [27] and their verifiable ver-sions [28] also do not allow granular rate limiting. Wenote that the Jarecki, Kiayias, and Krawczyk construc-tions of verifiable OPRFs [28] in the RO model areessentially the Ford-Kaliski protocol above, but withan extra hash computation, making the PRF outputH ′(t ‖m ‖H(t ‖m)kw). Our notion of one-more un-predictability in the appendix captures the necessary re-quirements on the inner cryptographic component, andmight modularize and simplify their proofs. Their trans-form is similar to the unique blind signature to OPRFtransformation of Camenisch, Neven, and shelat [16].None of these efficient oblivious PRF protocols supportkey rotations (with compact tokens or otherwise) as thefinal hashing step destroys updatability.

The setting of capture-resilient devices shares withours the use of an off-system key-holding server and thedesire to perform cryptographic erasure [32, 33]. Theyonly perform protocols for encryption and signing func-tionalities, however, and not (more broadly useful) PRFs.They also do not support granular rate limiting and mas-ter secret key rotation.

Our main construction coincides with prior onesfor other contexts. The Sakai, Ohgishi, and Kasa-hara [44] identity-based non-interactive key exchange

protocol computes a symmetric encryption key ase(H1(ID1), H2(ID2))

k for k a master secret held bya trusted party and ID1 and ID2 being the identitiesof the parties. See [41] for a formal analysis of theirscheme. Boneh and Waters suggest the same construc-tion as a left-or-right constrained PRF [13]. The settingsand their goals are different from ours, and in particularone cannot use either as-is for our applications. Naıvelyone might hope that returning the constrained PRF keyH1(t)

kw to the client suffices for our applications, butin fact this totally breaks rate-limiting. Security analysisof our protocol requires new techniques, and in particu-lar security must be shown to hold when the adversaryhas access to a half-blinded oracle — this rules out thetechniques used in [13, 41].

Key-updatable encryption [11] and proxy re-encryption [9] both support key rotation, and couldbe used to encrypt password hashes in a way support-ing compact update tokens and that prevents offlinebrute-force attacks. But this would require encryptionand decryption to be handled by the hardening service,preventing message privacy.

Verifiable PRFs as defined by [21,22,31,36] allow oneto verify that a known PRF output is correct relative to apublic key. Previous verifiable PRF constructions are notoblivious, let alone partially oblivious.

Threshold and distributed PRFs [21, 37, 40] as well asdistributed key distribution centers [40] enable a suffi-ciently large subset of servers to compute a PRF output,but previous constructions do not provide the granularrate limiting and key rotation we desire. However, it isclear that there are situations where applications wouldbenefit from a threshold implementation of PYTHIA, forboth redundancy and distribution of trust, as discussed inSection 6.2 for the case of brainwallets.

8 Conclusion

We presented the design and implementation of PYTHIA,a modern PRF service. Prior works have explored the useof remote cryptographic services to harden keys derivedfrom passwords or otherwise improve resilience to com-promise. PYTHIA, however, transcends existing designsto simultaneously support granular rate limiting, efficientkey rotation, and cryptographic erasure. This set of fea-tures, which stems from practical requirements in appli-cations such as enterprise password storage, proves torequire a new cryptographic primitive that we refer to asa partially oblivious PRF.

Unlike a (fully) oblivious PRF, a partially obliviousPRF causes one portion of an input to be revealed tothe server to enable rate limiting and detection of on-line brute-force attacks. We provided a bilinear-pairingbased construction for partially oblivious PRFs that is

12


highly efficient and simple to implement (given a pair-ings library), and also supports efficient key rotations. Aformal proof of security is unobtainable using existingtechniques (such as those developed for fully obliviousPRFs). We thus gave new definitions and proof tech-niques that may be of independent interest.

We implemented PYTHIA and show how it may beeasily integrated it into a range of applications. We de-signed a new enterprise “password onion” system thatimproves upon the one recently reported in use at Face-book. Our system permits fast key rotations, enablingpractical reactive and proactive key management, anduses a parallelizable onion design which, for a given au-thentication latency, imposes more computational efforton attackers after a compromise. We also explored theuse of PYTHIA to harden brainwallets for cryptocurren-cies.

Acknowledgements

The authors thank Kenny Paterson for feedback on anearly draft of this paper. This work was supported in partby NSF grants CNS-1330308, CNS-1065134, and CNS-1330599, as well as a gift from Microsoft.

References[1] Masayuki Abe and Tatsuaki Okamoto. Provably secure partially

blind signatures. In Advances in Cryptology–CRYPTO. Springer,2000.

[2] D. F. Aranha and C. P. L. Gouvea. RELIC is an Efficient LI-brary for Cryptography. https://github.com/relic-toolkit/relic.

[3] Ali Bagherzandi, Stanislaw Jarecki, Nitesh Saxena, and YanbinLu. Password-protected secret sharing. In Computer and Com-munications Security. ACM, 2011.

[4] Paulo SLM Barreto and Michael Naehrig. Pairing-friendly el-liptic curves of prime order. In Selected Areas in Cryptography.Springer, 2006.

[5] Mihir Bellare, Sriram Keelveedhi, and Thomas Ristenpart. Du-pless: server-aided encryption for deduplicated storage. InUSENIX Security. USENIX, 2013.

[6] Mihir Bellare, Chanathip Namprempre, David Pointcheval,Michael Semanko, and Matthew Franklin. The one-more-RSA-inversion problems and the security of Chaum’s blind signaturescheme. Journal of Cryptology, 16(3), 2003.

[7] Technical background of version 1 Bitcoin addresses.https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses.

[8] Bitcoin wiki, “weaknesses”. https://en.bitcoin.it/wiki/Weaknesses.

[9] Matt Blaze, Gerrit Bleumer, and Martin Strauss. Divertible proto-cols and atomic proxy cryptography. In Advances in Cryptology–EUROCRYPT. Springer, 1998.

[10] Alexandra Boldyreva. Threshold signatures, multisignatures andblind signatures based on the gap-Diffie-Hellman-group signaturescheme. In Public Key Cryptography. Springer, 2002.

[11] Dan Boneh, Kevin Lewi, Hart Montgomery, and Ananth Raghu-nathan. Key homomorphic PRFs and their applications. In Ad-vances in Cryptology–CRYPTO. Springer, 2013.

[12] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signaturesfrom the Weil pairing. In Advances in Cryptology–ASIACRYPT.Springer Berlin Heidelberg, 2001.

[13] Dan Boneh and Brent Waters. Constrained pseudorandomfunctions and their applications. In Advances in Cryptology-ASIACRYPT. Springer, 2013.

[14] Brainwallet. https://en.bitcoin.it/wiki/Brainwallet.

[15] Jan Camenisch, Anna Lysyanskaya, and Gregory Neven.Practical yet universally composable two-server password-authenticated secret sharing. In Computer and CommunicationsSecurity. ACM, 2012.

[16] Jan Camenisch, Gregory Neven, and abhi shelat. Simulat-able adaptive oblivious transfer. In Advances in Cryptology–EUROCRYPT. Springer Berlin Heidelberg, 2007.

[17] Jan Camenisch and Markus Stadler. Proof systems for generalstatements about discrete logarithms. Technical Report No. 260,Dept. of Computer Science, ETH Zurich, 1997.

[18] David Chaum. Blind signatures for untraceable payments. InAdvances in Cryptology. Springer, 1983.

[19] David Chaum and Torben Pryds Pedersen. Wallet databases withobservers. In Advances in Cryptology–CRYPTO. Springer, 1993.

[20] Mario Di Raimondo and Rosario Gennaro. Provably securethreshold password-authenticated key exchange. In Advances inCryptology–EUROCRYPT. Springer, 2003.

[21] Yevgeniy Dodis. Efficient construction of (distributed) verifiablerandom functions. In Public Key Cryptography. Springer, 2002.

[22] Yevgeniy Dodis and Aleksandr Yampolskiy. A verifiable randomfunction with short proofs and keys. In Public Key Cryptography.Springer, 2005.

[23] Paul Ducklin. Anatomy of a password disaster – Adobe’sgiant-sized cryptographic blunder, 2013. https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/.

[24] Taher ElGamal. A public key cryptosystem and a signaturescheme based on discrete logarithms. In Advances in Cryptology–CRYPTO. Springer, 1985.

[25] Adam Everspaugh, Rahul Chatterjee, Samuel Scott, Ari Juels,and Thomas Ristenpart. The Pythia PRF service. Full ver-sion of this paper. http://pages.cs.wisc.edu/˜ace/papers/pythia.pdf.

[26] Warwick Ford and Burton S. Kaliski, Jr. Server-assisted genera-tion of a strong secret from a password. In International Work-shops on Enabling Technologies: Infrastructure for Collabora-tive Enterprises. IEEE, 2000.

[27] Michael J Freedman, Yuval Ishai, Benny Pinkas, and Omer Rein-gold. Keyword search and oblivious pseudorandom functions. InTheory of Cryptography. Springer, 2005.

[28] Stanislaw Jarecki, Aggelos Kiayias, and Hugo Krawczyk.Round-optimal password-protected secret sharing and t-PAKEin the password-only model. In Advances in Cryptology–ASIACRYPT. Springer, 2014.

[29] Max Krohn and Chris Coyne. Wrap Wallet. https://keybase.io/warp.

[30] Moses Liskov, Ronald L Rivest, and David Wagner. Tweakableblock ciphers. In Advances in Cryptology–CRYPTO. Springer,2002.

13


[31] Anna Lysyanskaya. Unique signatures and verifiable ran-dom functions from the DH-DDH separation. In Advances inCryptology–CRYPTO. Springer, 2002.

[32] Philip MacKenzie and Michael K Reiter. Delegation of crypto-graphic servers for capture-resilient devices. Distributed Com-puting, 16(4), 2003.

[33] Philip MacKenzie and Michael K Reiter. Networked crypto-graphic devices resilient to capture. International Journal of In-formation Security, 2(1), 2003.

[34] Philip MacKenzie, Thomas Shrimpton, and Markus Jakobsson.Threshold password-authenticated key exchange. In Advances inCryptology–CRYPTO. Springer, 2002.

[35] R. McMillan. The inside story of Mt. Gox, bitcoin’s $460 milliondisaster. Wired, 2014.

[36] Silvio Micali, Michael Rabin, and Salil Vadhan. Verifiable ran-dom functions. In Foundations of Computer Science. IEEE, 1999.

[37] Silvio Micali and Ray Sidney. A simple method for generat-ing and sharing pseudo-random functions, with applications toclipper-like key escrow systems. In Advances in Cryptology–CRYPTO. Springer, 1995.

[38] Alec Muffet. Facebook: Password hashing & authentication. Pre-sentation at Real World Crypto, 2015.

[39] Allec Muffet. Facebook: Password hashing and au-thentication. https://video.adm.ntnu.no/pres/54b660049af94.

[40] Moni Naor, Benny Pinkas, and Omer Reingold. Dis-tributed pseudo-random functions and KDCs. In Advances inCryptology–EUROCRYPT. Springer, 1999.

[41] Kenneth G Paterson and Sriramkrishnan Srinivasan. On the re-lations between non-interactive key distribution, identity-basedencryption and trapdoor discrete log groups. Designs, Codes andCryptography, 52(2), 2009.

[42] David Pointcheval and Jacques Stern. Provably secure blindsignature schemes. In Advances in Cryptology–ASIACRYPT.Springer, 1996.

[43] Jim Roskind. QUIC: Multiplexed stream transport over UDP.Google working design document, 2013.

[44] R. Sakai, K. Ohgishi, and M. Kasahara. Cryptosystems based onpairing. In Cryptography and Information Security, 2000.

[45] Adi Shamir. How to share a secret. Communications of the ACM,22(11):612–613, 1979.

A Additional PYTHIA API details

Many PYTHIA-dependent services can benefit from ad-ditional API features and calls beyond the primary onesdiscussed in the body of the paper. (For example, thePYTHIA password onion system in Section 5 uses theTransfer API call.) We detail these other API features inthis appendix.

Key-management options. The client can specify anumber of options in the call Init regarding managementof the ensemble key kw. The client can provide a contactemail address to which alerts and authentication tokensmay be sent. (If no e-mail is given, no API calls requiringauthentication are permitted at present and no alerts areprovided. Later versions of PYTHIA will support otherauthentication and alerting methods.)

Selector option DescriptionEmail Contact email for selectorResettable Whether client-requested rotations allowedLimit Establish rate-limit per tTime-out Date/time to delete kwPublic-key Key under which to encrypt and store up-

date and authentication tokensAlerts Whether to email contact upon rate limit vi-

olation

Figure 9: Optional settings for establishing key selectorsin PYTHIA.

Command DescriptionTransfer(w,w′ [, options]) Creates new ensemble

w′; outputs update token∆w→w′ ; resets kw

SendTokens(w, authtoken) Sends stored update tokens toclient

PurgeTokens(w, authtoken) Purges all stored update to-kens for ensemble w

Figure 10: The PYTHIA API. The individual calls areexplained in detail in the text.

The client can specify whether kw should be resettable(default is “yes”). The client can specify a limit on thetotal number of Fkw

queries that should be allowed be-fore resetting K[w] (default is unlimited) and/or an ab-solute expiration date and time in UTC at which pointK[w] is deleted (default is no time-out). Either of theseoptions overrides the resettable flag. The client can spec-ify a public key pkcl for a public-key encryption schemeunder which to encrypt authentication tokens and updatetokens (for Reset, Transfer, as described below, and formaster secret key rotations). Finally, the client can re-quest that alerts be sent to the contact email address inthe case of rate limit violations. This option is ignoredif no contact email is provided. The options are summa-rized in Figure 9.

PYTHIA also offers some additional API calls, givenin Figure 10, which we now describe.

Ensemble transfer. A client can create a new ensemblew′ (with the same options as in Init) while receiving anupdate token that allows PRF outputs under ensemble wto be rolled forward to w′. This is useful for importinga password database to a new server. The PYTHIA ser-vice returns an update token ∆w→w′ for this purpose andstores it encrypted under pkcl. For the case w′ = w, thiscall also allows option updates on an existing ensemblew.

Update-token handling. The PYTHIA service storesupdate tokens encrypted under pkcl, with accom-panying timestamps for versioning. The API callSendTokens causes these to be e-mailed to the client,

14


while PurgeTokens causes update-token ciphertexts tobe deleted from PYTHIA.

Note that once an update token is deleted, old PRFvalues to which the token was not applied become cryp-tographically erased — they become random values un-related to any messages. A client can therefore delete thekey associated with an ensemble by calling Reset andPurgeTokens.

Master secret rotations. PYTHIA can also rotate itsmaster secret key msk to a new key msk′. Recall that en-semble keys are computed as kw = HMAC(msk,K[w]),so rotation of msk results in rotation of all ensemblekeys. To rotate to a new msk′, the server computes kwfor all ensembles w with entries in K, and stores δw en-crypted under pkcl. If no encryption key is set, then thetoken is stored in the clear. This is a forward-securityissue while it remains, but only for that particular keyensemble. At this point msk is safe to delete. Clientscan be informed of the key rotation via e-mail.

Subsequent SendTokens requests will return the re-sulting update token, along with any other stored updatetokens for the ensemble. If multiple rotations occur be-tween client requests, then these can be aggregated in thestored update token for each ensemble. This is trivial ifthey are stored in the clear (just multiply the new tokenagainst the old) and also works if they are encrypted withan appropriately homomorphic encryption scheme suchas ElGamal [24].

B Formal Security Analyses

We provide formal security notions for partially oblivi-ous PRFs, and proofs of security relative to them for ourscheme from Section 3.

Partially-oblivious PRFs. A partially oblivious PRFprotocol Π = (K, PRF-Cl, PRF-Srv, F ) consists of thefollowing. The key generation algorithm K outputs apublic key and private key pair (pk, sk). We assumethat from sk one can compute pk easily. The PRF-Srvalgorithm takes input the secret key sk and a client re-quest message (a bit string) and returns a server re-sponse message (another bit string). The client algo-rithm PRF-Cl takes inputs a tweak t and message m,can make a single call to PRF-Srv, and outputs a value.Finally we associate to the protocol a keyed functionFsk : {0, 1}∗ × {0, 1}∗ → {0, 1}∗. A scheme is correctif executing PRF-ClPRF-Srvsk(·)(t,m) with fresh coinsmatches Fsk(t,m) with probability one. In words, theprotocol computes the appropriate function of t,m.

Bilinear pairing setups. Let G1,G2,GT be groupsall of order p that have associated to them an admissi-ble bilinear pairing e : G1 × G2 → GT . Recall that

for generators g1 ∈ G1, g2 ∈ G2, there exists a gen-erator gT ∈ GT such that e(gα1 , g

β2 ) = gαβT for all

α, β ∈ p. As shorthand for below we refer to a pair-ing setup G = (g1, g2, gT ,G1,G2,GT , e) and assumesome compact description of G as a bit-string where ap-propriate.

The scheme. The partially-oblivious PRF at the core8 ofour bilinear pairing scheme from Section 3 is as followsfor some fixed pairing setup G. Let H1 : {0, 1}∗ → G1

and H2 : {0, 1}∗ → G2 be hash functions that we willlater model as random oracles.

Key generation K picks a random exponent sk andcomputes a public key pk = gs1k. The PRF-Cl(t,m)algorithm computes a mask r←$ p and sends t andx = H2(m)r to the server. The PRF-Srv(sk, t, x) com-putes y = e(H1(t), x)

sk and a ZKP π that DLg1(pk) =DLx(y) where x = e(H1(t), x). It sends pk, y, π to theclient, who verifies the ZKP, deletes it, and then outputsy1/r. The correctness of the scheme follows from thecorrectness of the ZKP and the properties of the pairing.

The ZKP is used to ensure that a malicious server re-sponds as per the protocol. In the following securityanalyses we focus primarily on malicious clients, and forsimplicity analyze a simpler version of the protocol thatomits the ZKP. The proofs found below can be extendedto the full protocol by applying the zero-knowledge se-curity of the proof systems that we use (i.e., use thezero-knowledge simulator to produce fake, but realistic-looking to the client, proofs).

B.1 Unpredictability Security

We define a one-more unpredictability security notion.It modifies one-more unforgeability [42] to be suitablefor the setting of unpredictable functions (as opposed topublicly verifiable signatures). The game is shown inFigure 11. We associate to any protocol Π, adversary A,and query number q the one-more-unpredictability ad-vantage defined as

Advom-unpΠ,q (A) = Pr

[om-UNPA

Π,q ⇒ true].

The probability here (and for games defined later below)is over all random coins used by the procedures and theadversary. The event refers to the probability that thevalue returned by the main procedure is true. In words,the definition requires that an adversary cannot produce �outputs of the PRF using less than � queries on partially-blinded inputs to the server. One can easily extend thisnotion to deal with full blinded inputs as well, but wewill not need this.

8For brevity we omit key selectors here, and instead focus on ana-lyzing security for a single key instance. Assuming properly generatedkeys for each selector, one can show that security for a single key in-stance implies security for many.

15


Game om-UNPAΠ

(pk, sk)←$ Kc ← 0

(t1,m1, σ1), . . . , (t�,m�, σ�)←$ APRF-Srv,H1,H2

If ∃i �= j . (ti,mi) = (tj ,mj) then Ret falseRet (∧i(σi = FH1,H2

sk (ti,mi)) ∧ c < �)

PRF-Srv(t, Y )

c ← c+ 1

Ret PRF-SrvH1,H2sk (t, Y )

Figure 11: Security game for one-more unpredictability.

This notion of security is sufficient for PYTHIA in ap-plications where the output of the protocol is not stored,but rather used as an unforgeable credential such as withour hardened Brainwallet application (Section 6).

The security of our scheme is based on the fol-lowing one-more bilinear computational Diffie-Hellman(BCDH) problem, an extension of the one-more CDHassumption given by Boldyreva [10]. To the bestof our knowledge this assumption is new, but it isa straightforward adaptation of previous one-more as-sumptions [6, 10] to our setting. For a pairing setup G,game om-BCDHG is defined in Figure 12. In words, theadversary gets a group element gs1k ∈ G1 as well astarget oracles Targ1,Targ2 that return random group ele-ments in G1,G2 respectively. Finally the adversary canquery a helper oracle Help that raises GT elements to thek. To win, it must compute � values e(Xi, Yj)

k for �larger than the number of helper queries and each Xi, Yj

a unique pair of (distinct) values returned by the target or-acle. Let Advom-cdh

G (B) = Pr[

om-BCDHBG ⇒ true

].

We have the following theorem establishing the one-more unpredictability of our scheme The proof is essen-tially identical to the proof of Boldyreva’s blind signa-tures [10].

Theorem 1 Let Π be the simplified partially obliviousPRF protocol for a pairing setup G and H1, H2 mod-eled as random oracles. Then for any one-more un-predictability adversary A making at most q PRF-Srvqueries, we give in the proof below a one-more CDH ad-versary B such that

Advom-unpΠ (A) ≤ Advom-cdh

G (B)where B runs in time that of A plus O(q) group opera-tions.

Proof: We assume without loss of generality that Anever repeats a query to either random oracle and makesa random oracle H1(ti) and H2(mi) query for each(ti,mi, σi) triple it outputs. The adversary B will workas follows when given inputs G, X and access to oraclesTarg1,Targ2,Help. First, it runs A. Whenever A makes

Game om-BCDHBG

sk ←$ p

qh, q1,t, q2,t ← 0

(i1, j1, σ1), . . . , (i�, j�, σ�)←$ ATarg1,Targ2,Help(G, gs1k)

If qh ≥ � then Ret falseIf ∃α . (iα > q1,t) ∨ (jα > q2,t) then Ret falseIf ∃α �= β . (iα, jα) = (iβ , jβ) then Ret falseRet ∀α . e(Xiα , Yjα)

k = σα

Targ1

q1,t ← q1,t + 1 ; Xq1,t ←$ G1 ; Ret Xq1,t

Targ2

q2,t ← q2,t + 1 ; Yq2,t ←$ G2 ; Ret Yq2,t

Help(Z)

qh ← qh + 1 ; Ret Zsk

Figure 12: Security game for a one-moreBCDH assumption for bilinear pairing settingG = (g1, g2, gt,G1,G2,GT , e).

an H1(t) query, B queries Targ1 to obtain a G1-elementthat we will denote X[t], sets ct to be the number of H1

queries so far (including the current), and returns X[t]to A. Whenever A makes an H2(m) server query, Bqueries Targ2, obtains a G2-element that we will denoteY [m], sets dm to be the number of H2 queries so far (in-cluding the current), and returns Y [m] to A. WheneverA makes a PRF-Srv(t, Y ) query, the adversary B com-putes Z ← e(H1(t), Y ), and then queries Z to its helperoracle Help to obtain a value σ ∈ GT . It returns σ to A.

Eventually A outputs a series of triples(t1,m1, σ1), . . . , (tq,mq, σq). At this pointadversary B outputs the sequence of pairs(ct1 , dm1

, σ1), . . . , (cmq, dmq

, σq).Suppose A wins its game. Then it made at most q − 1

queries to PRF-Srv and so B makes at most q−1 queriesto Help. It is also the case that all predictions by A arefor unique tag, message pairs, meaning that B’s outputwill also be for unique pairs of targets. Finally, it is clearthat correct predictions σi are also BCDH solutions.

B.2 Pseudorandomness SecuritySee the full version of this paper [25] for one-more PRFsecurity definitions and associated proofs.

16

the pythia prf service - usenix · usenix association 24th usenix security symposium 547 the pythia...

Documents