SRS Whitepaper
A secure recovery service with the shortest viable mnemonic. Recover and authenticate everything with 4 words.
Stefan Hechenberger (Blockshake), Kevin Wellenzohn (Blockshake), Fabrice Benhamouda (Algorand Foundation), Shai Halevi, Hugo Krawczyk (Algorand Foundation), Tal Rabin (University of Pennsylvania)
SRS is a secure, multi-party retrieval service that simplifies non-custodial crypto wallets. It eliminates the need for remembering lengthy recovery phrases by using convenient 4-word mnemonics. Unlike HD wallets, SRS allows an arbitrary set of secrets to be stored and recovered with one short phrase. It supports use cases for both long-term vaulting of secrets and daily joint-custodial wallet transaction signing.
Web3 and DeFi require users to take responsibility for securing private keys. Keeping account secrets safe is a central challenge. The current system of writing down long recovery phrases places a high burden on the user and can compromise the essential properties of security, availability, and usability.
To address these challenges, SRS proposes a chain- and wallet-agnostic service that stores user secrets securely with remarkably short recovery phrases. SRS achieves this through a combination of techniques:
The phrase is randomly generated, making dictionary attacks ineffective.
The phrase is strengthened through a threshold OPRF, which is rate-limited to prevent brute-force guessing attacks.
The phrase is aggressively fortified client-side with Argon2, a compute- and memory-hard function that makes computing a significant number of potential passwords very costly. Client-side hardening allows us to give users the best security that their hardware affords.
Overview
The core concept behind SRS is to enable complete recovery with just four mnemonic words and a uniquely chosen name by the user. These five words form the user's SRSID and provide unrestricted access to their secrets on any device, including those that are new or borrowed. Thus, no other user data is necessary.
The primary objective of the SRS backend is two-fold: to increase the entropy of the SRSID from 51.7 bits to 128 bits and to vault the final ciphertext containing the user's secrets. Furthermore, the backend provides the parameters necessary for additional, client-side, key-strengthening techniques.
Basic Use Case
To interact with SRS, a user undergoes the following steps. This would typically be implemented by their wallet app :
Generate an SRSID: The user creates a unique SRS Identity (SRSID), which consists of a username and a passphrase. The passphrase is composed of four random words from the EFF Long Word List. An optional fifth user-defined word can be specified to arbitrarily increase the entropy of the key.
Use OPAQUE to compute a strong key: The user interacts with the SRS Indexer and utilizes the OPAQUE protocol to derive a strong cryptographic key from the SRSID. OPAQUE is a secure password-authenticated key exchange protocol that prevents the leakage of user credentials.
Store Argon2 parameters on OPAQUE server: During the OPAQUE registration process, the user stores their Argon2 parameters on the SRS Indexer. Argon2 is a compute- and memory-hard key derivation function (KDF) that helps strengthen the derived cryptographic key.
Fortify the strong key with Argon2: The user processes the strong key derived using OPAQUE through the Argon2 KDF, which takes the Argon2 parameters stored earlier. This step further strengthens the key, making it more resilient against brute-force attacks.
Encrypt wallet data with the stronger key: The user encrypts their wallet data (e.g., private keys, seed phrases) using the key obtained from the Argon2 KDF. This encryption ensures that the wallet data remains secure from unauthorized access even when the ciphertext leaks.
Store encrypted wallet data: Finally, the user stores the encrypted wallet data in our managed SRS Vault service or in a personal storage service (e.g., Dropbox, etc.). The SRS Vault is designed for availability and convenience, and is well-integrated with the rest of SRS. On the other hand, storing the encrypted wallet data by oneself means an attacker needs another tailor-made step to compromise a user.
Background
Argon2
Argon2 is a key-derivation function (KDF) that is designed to be slow and resource-intensive to make it slow and expensive for attackers to compute a large number of hash values. To control Argon2’s resource-usage, it is parameterized by the number of iterations that it performs (controlling CPU cost), the amount of memory it uses (controlling space usage), and the level of parallelism it is allowed to use. Argon2 is the winner of the Password Hashing Competition and recommended by OWASP.
We use Argon2 client-side during password authentication to harden a derived cryptographic key and make brute-force attacks expensive. Running Argon2 client-side as opposed to server-side (where it is typically used) has a number of advantages. To inflict the maximum cost on a possible attacker we adapt the parameters to the user's hardware and run it as long as the UI/UX of the wallet allows. While servers tend to be more powerful than client devices, they are shared by many users and cannot run an expensive, long-lasting Argon2 computation for each user. On a user’s device, Argon2 can exhaust the existing hardware and run as long as the user experience permits. Attackers that try to brute-force guess passphrases, need to apply Argon2 on each authentication attempt, making the guesswork extremely slow and expensive.
OPRF
The Oblivious Pseudo-Random Function (OPRF) – standardized here – is a two-party protocol to deterministically compute a function OPRFS(P) between a client that holds a passphrase P and a server that holds a cryptographic key S. The output K = OPRFS(P) of the OPRF is a strong cryptographic key. The protocol guarantees that after the protocol completes, the server does not learn anything about the user’s passphrase P or the function’s output K. The user, on the other hand, obtains K but does not learn anything about the server’s key S. OPRF is a stateless protocol, meaning that an OPRF server does not store any state (e.g., user data) other than its key S. The OPRF protocol can be used as a blackbox to turn a user’s low-to-medium entropy passphrase P into a high-entropy cryptographic key K that is further hardened with Argon2.
The OPRF protocol proceeds in three steps and exchanges two messages (one from client to server, and one from server to client):
(Blinding) The client blinds passphrase P with a securely-generated random number. Only the blinded passphrase is sent to the server, the random number is kept in memory until the OPRF protocol completes and is forgotten afterwards.
(Evaluation) The server evaluates the blinded passphrase with its master key S and sends the evaluated message back to the client.
(Unblinding) The client unblinds the evaluated message using the random number from step one to obtain the OPRF output K. In SRS, we additionally fortify the OPRF output with Argon2 to obtain a strong cryptographic key.
We consider two extensions to the basic OPRF protocol: the partially-oblivious PRF (POPRF) protocol and the threshold-POPRF protocol.
The POPRF protocol adds a public input I to the protocol to compute K = POPRFS(P, I). The public input is provided by the user and, unlike passphrase P, can be seen by the server. What exactly the public input contains depends on the application, but it could for example be an account or user identifier. For us, input I will prove useful to rate-limit the POPRF protocol to prevent abuse.
The threshold-POPRF protocol turns the two-party OPRF protocol into a multi-party protocol between a client and a set of n servers. A user needs to talk to at least a threshold t out of n servers to compute K = POPRFS(P, I), where the threshold is defined by the system. In this distributed setup, each server has a share of the global master key S that is constructed using some linear secret-sharing scheme (e.g. Shamir). The threshold-POPRF protocol is useful to increase the security of the system and make it more fault tolerant since no single server knows the entire master key S and the system can sustain n-t server losses/outages and still be able to compute K = POPRFS(P, I).
In the following we write OPRF to denote the threshold-POPRF protocol.
OPAQUE
Password authentication is the most commonly used authentication mechanism that exists today. In these systems, the users send their passphrase to a server, which in turn checks if the passphrase matches the one stored in a database. Current systems are flawed in several ways. For example, users need to send passphrases in cleartext to the server (albeit hopefully encrypted in transit). This makes the passphrase vulnerable to mishandling on the server’s side, e.g., by inadvertently logging all passphrases or storing them in plaintext.
Password Authenticated Key Exchange (PAKE) protocols exist that allow clients to authenticate to a server without revealing their passphrase. OPAQUE is the state-of-the-art instantiation of a PAKE with several useful properties: (1) users never have to share their passphrase with the server, neither during registration nor authentication; (2) composes well with key-stretching primitives like Argon2 that make guessing attacks very expensive; and (3) allows applications to derive a strong cryptographic key (OPRF key K, hardened by Argon2) that can be used to securely encrypt and store arbitrary application data.
OPAQUE (standardized here) builds on top of the OPRF protocol and is, unlike OPRF, a stateful protocol. This means users have accounts that they need to register and the server maintains a database with these accounts. During authentication, OPAQUE uses OPRF to prove knowledge of a passphrase without revealing that passphrase. We briefly look at user registration and authentication in turns.
User registration proceeds in three steps and exchanges three messages between client and server:
The client blinds passphrase P and transmits it along with the user identity I to the server.
The server evaluates the blinded passphrase and sends it back to the client.
The client unblinds the evaluated message to obtain the OPRF output K, which it additionally fortifies with Argon2. The client creates a record (in cleartext) that contains user information (username, etc.) and an envelope that is authenticated with the stretched OPRF key. Importantly, the envelope also contains in cleartext the Argon2 parameters that the client has chosen. To finalize the registration, the record is sent to the server that stores it in its account database.
User authentication works similarly:
The client blinds passphrase P and transmits it along with the user identity I to the server.
The server evaluates the blinded passphrase and sends it, along with I’s record stored during registration, back to the client.
The client unblinds the message, takes the Argon2 parameter from the record, and fortifies the OPRF output with Argon2. From this OPRF output, the protocol derives an export_key and a session_key. The former is only known to the client and can be used to encrypt client secrets, the latter is known by both client and server. The client authenticates the envelope and learns if the authentication was successful. The wallet sends a MAC to the server to prove authentication upon which the server learns if the user provided the correct passphrase.
We use OPAQUE as a secure authentication mechanism for SRS and its services. For example, we offer a Vault service where users can safely store their encrypted account secrets.
Architecture
Users turn to their crypto wallets (e.g., Metamask, Trust Wallet, Defly Wallet, etc.) to manage their crypto accounts. Wallets can integrate SRS to let their users seamlessly and securely backup and restore their account secrets. This means any new account they create can simply be added to SRS and recovered with the convenience of the SRSID.
SRS consists of three services: (a) the SRS Indexer that keeps track of user accounts and implements the OPAQUE protocol, (b) the SRS Vault that stores the users’ encrypted secrets, and (c) the federated Oracle servers that are involved during password authentication in the OPAQUE protocol.
SRS Indexer
The SRS Indexer is responsible for user registration and authentication, using the OPAQUE protocol under the hood. User accounts are purely pseudonymous without relying on user identifying information. The primary function of the indexer is to assure the uniqueness of user-chosen names and store the associated Argon2 parameters.
SRS Oracle
The SRS Oracle consists of a set of n federated OPRF servers that are used as part of the OPAQUE protocol to authenticate the user to SRS. At least t out of n OPRF servers are required during authentication. Each Oracle server holds its own shard of a master key S that is derived from some linear secret-sharing scheme (e.g, Shamir).
SRS Vault
The Vault offers an API for wallets to store and retrieve ciphertexts. It stores encrypted user secrets that are automatically addressed by SRS. The primary function of the Vault is to ensure that ciphertexts are always available. While users have the option to place their ciphertext in their own custody, this adds another step in the recovery process and places additional burden on them. Therefore, the Vault adds convenience and availability to the SRS system.
SRS Protocol
In the following we describe how SRS works on a high-level. This description is not meant as a full technical specification of the protocol.
User Credentials – SRSID
SRS is designed to reduce the cognitive load placed on users who have to remember and access-control an ever growing collection of 12 to 25-word recovery phrases.
With SRS, users only need to remember one short and easily memorable SRS Identity (SRSID) to safely back up and restore their account secrets. The SRSID = (N, P) consists of a unique username N and a passphrase P. Remembering a username and a passphrase is something most people are accustomed to.
Passphrase P consists of:
Four random words from the EFF Long Word List that contains 7776 words.
An optional fifth user-defined word that does not need to be in the EFF Long Word List. This fifth word can be arbitrarily complex. This allows the user to arbitrarily increase the difficulty of brute-force attacks.
An example SRSID looks like this:
N = john
P = abacus blitz crimson dolphin
Passphrase P offers at least 51 bits of entropy (since log2(7776**4) = 51.69 bits) and a user can increase the entropy by adding the fifth user-defined word if they want to. While 51 bits of entropy is considered a medium-strength passphrase, SRS hardens this passphrase using OPAQUE and key-stretching to derive a strong cryptographic key.
Registration
Users need to sign up for an SRS account and register their SRSID to use the system. From a user’s point of view this works as follows. The user opens her crypto wallet that integrates SRS and chooses to create a new account. The wallet then interacts with the user to generate (but not yet register) an SRSID:
The wallet asks the user for a username.
The wallet presents the user a randomly generated four-word mnemonic phrase using the EFF Long Word List and asks her to remember these four words. The wallet must use a secure random number generator in this process and it cannot allow users to generate a new four-word mnemonic (to prevent a situation where users keep generating new phrases until they like the resulting words). It is important that wallet providers follow our recommendations, but in practice SRS cannot enforce these rules since passphrases are blinded before being sent to SRS servers.
Optionally, the wallet may ask the user for a fifth word.
In addition, the wallet chooses appropriate parameters for the Argon2 key-stretching function. Recall that Argon2 is parameterized by the number of iterations (controlling CPU usage), the amount of memory (controlling RAM usage), and the level of parallelism. These parameters depend on the user’s device and the goal is to use values that make the computation of Argon2 slow but feasible on the device (e.g., taking a couple of seconds without crashing the user’s device). For example, if the user has a mobile device with 6 cores and 6GB of memory, it may be appropriate to use 10 iterations on 5 cores and 5GB of memory. A possible algorithm to choose Argon2 parameters is to start with one iteration and set the memory size to 75% of the system’s memory and the level of parallelism to the number of cores minus one. Measure the time it takes to compute Argon2 and scale that up to the desired runtime by increasing the number of iterations (the runtime scales linearly with the number of iterations).
Having generated an SRSID and chosen the Argon2 parameters, the wallet calls the SRS Indexer to register the user. Registration proceeds as defined by OPAQUE above. In the second step of the OPAQUE registration, the Indexer server evaluates the OPRF protocol by talking to at least t out of n Oracle servers. This is completely transparent to the user who never needs to talk to the Oracle servers directly. The Indexer server blinds the user’s username N and picks it as public input to the OPRF protocol. Blinding the username makes sure that it does not leak to the Oracle servers in cleartext. To blind a username we apply a pseudorandom function PRFk(N) that is parameterized by a secret key k that only SRS Indexers know.
After the registration is complete, the user has obtained an SRSID and the server has stored a user record in its database.
Authentication
When users want to back up or recover their account secrets, they need to log in to SRS through their wallet. The wallet prompts them for their SRSID and initiates authentication, which proceeds as described in Section OPAQUE above. During authentication, the wallet learns the export_key that can be used to encrypt/decrypt the user’s account secrets.
In the second step, when the server receives the user’s blinded passphrase and username, the server can respond with a fake record in case the user does not exist. This is to prevent user enumeration attacks where an attacker tries to find out what usernames have registered for the service.
Backing up and Recovering Account Secrets
Once a user has signed in to SRS, they can back up and/or recover their account secrets. During the authentication process, users obtained an export_key, which is a strong cryptographic key that only the user knows and that can be used to securely encrypt data upon successful authentication at SRS.
The wallet asks the user what accounts should be backed up. It then proceeds to encrypt the selected account secrets with an authenticated encryption scheme using export_key as encryption key. We refer to the encrypted secrets as ciphertext.
Users can choose to store their ciphertext themselves, or use the SRS Vault to store it on SRS servers. Storing the ciphertext by themselves (e.g., locally on a computer or remotely on a private cloud) adds a level of security because even if the user’s SRS account is compromised, an attacker does not automatically have access to the ciphertext. On the other hand, storing the ciphertext on the SRS Vault adds a level of convenience since the Vault makes sure that the ciphertext is available without having to remember additional information such as location and access credentials. In addition, the Vault may provide versioning, such that users can look at the history of their backups.
Recovering account secrets works similarly. The user uses the export_key to decrypt either a local file or one from the SRS Vault.
The data format that the wallet uses to back up account secrets is not specified. There exist a number of standards that define a data format for account credentials, e.g., see ARC-35 for Algorand or Universal Wallet 2020 for a wallet-agnostic format. Different wallets that implement SRS may want to use a different data format. To support this, wallets may have their own namespace in the SRS Vault.
Security Considerations
Online Attacks
SRS uses randomly generated passphrases to make it ineffective for attackers to guess passphrases using dictionaries. However, attackers can still try to brute-force their way into SRS by guessing each passphrase.
To mitigate this risk, SRS limits the number of requests for each user account. If an excessive number of requests is detected, the system will reject new incoming requests for that user. This rate-limiting approach helps prevent attackers from repeatedly guessing passphrases and protects user accounts from unauthorized access.
This solution can lead to a second problem where a malicious actor denies a legitimate user access to the service (DOS attack) by querying the service until the rate limit is reached. We consider two solutions to these DOS attacks.
Users can register a secondary authentication mechanism, like email or an authenticator app to bypass rate limiting. If the normal authentication channel is blocked, users can use their secondary channel to reopen the primary OPAQUE authentication. For example, if a user is rate-limited, she can request an email with a special link that opens up a bypass authentication channel.
We can implement a base fee for each request, which the server can temporarily increase in response to a brute force guessing scenario. The base fee should be set at a reasonable amount to cover the cost of the SRS service and deter attackers from keeping the channel in high cost mode.
When the fee is in high cost mode, brute force guessing should become prohibitively expensive even with a low number of attempts (e.g. $10 per request). In the unlikely event that an attacker persists, users have the option to either wait it out or pay the temporarily increased fee.
The goal is to make it highly unlikely for an attacker to bump a user channel at the same time that the user is trying to go through recovery.
Offline Attacks
If an attacker is able to compromise SRS servers and steal user records or enough parts of the OPRF master key, they may try to mount an offline brute-force attack. An offline attack is much faster since it does not require (online) interactions with SRS services and is hence not inhibited by network latency or additional authentication factors.
To authenticate a given user with username N at SRS, three pieces of information are needed:
The user passphrase P (SRS servers only ever see a blinded version of P – never in cleartext)
At least t out of n shards of the OPRF master key S stored on SRS Oracle servers
The OPAQUE account record stored on the SRS Indexer servers since it contains the Argon2 parameters
The OPAQUE record with its Argon2 parameters is considered public information (this data is exchanged during an authentication attempt) and therefore not hidden from an attacker. This means that an attacker needs to compromise at least t Oracle servers to obtain enough master key shards before they can mount an offline brute-force attack on P.
Assuming an attacker is indeed successful in compromising enough servers, then the attacker must try, for each user on average, half of the 251 passphrases (which is the minimum entropy of our randomly-generated passphrases P). Each guess requires an evaluation of the OPAQUE protocol that involves computing the Argon2 for each passphrase guess, which is designed to be slow and resource-intensive. During registration, Argon2 parameters were chosen such that evaluating Argon2 takes several seconds on the user’s device. An attacker likely has more compute-power at its disposal, but 0.5*251 Argon2 evaluations still frustrate the most ambitious efforts.