13. Anastasis

Anastasis is a service that allows the user to securely deposit a core secret with an open set of escrow providers and recover it if the secret is lost. The core secret itself is protected from the escrow providers by encrypting it with a master key. The main objective of Anastasis is to ensure that the user can reliably recover the core secret, while making this difficult for everyone else. Furthermore, it is assumed that the user is unable to reliably remember any secret with sufficiently high entropy, so we cannot simply encrypt using some other key material in posession of the user.

To uniquely identify users, an “unforgettable” identifier is used. This identifier should be difficult to guess for anybody but the user. However, the identifier is not expected to have sufficient entropy or secrecy to be cryptographically secure. Examples for such identifier would be a concatenation of the full name of the user and their social security or passport number(s). For Swiss citizens, the AHV number could also be used.

The adversary model of Anastasis has two types of adversaries: weak adversaries which do not know the user’s identifier, and strong adversaries which somehow do know a user’s identifier. For weak adversaries the system guarantees full confidentiality. For strong adversaries, breaking confidentiality additionally requires that Anastasis escrow providers must have colluded. The user is able to specify a set of policies which determine which Anastasis escrow providers would need to collude to break confidentiality. These policies also set the bar for the user to recover their core secret.

A recovery document includes all of the information a user needs to recover access to their core secret. It specifies a set of escrow methods, which specify how the user should convince the Anastasis server that they are “real”. Escrow methods can for example include SMS-based verification, Video-identfication or a security question. For each escrow method, the Anastasis server is provided with truth, that is data the Anastasis operator may learn during the recovery process to authenticate the user. Examples for truth would be a phone number (for SMS), a picture of the user (for video identification), or the (hash of) a security answer. A strong adversary is assumed to be able to learn the truth, while weak adversaries must not. In addition to a set of escrow methods and associated Anastasis server operators, the recovery document also specifies policies, which describe the combination(s) of the escrow methods that suffice to obtain access to the core secret. For example, a policy could say that the escrow methods (A and B) suffice, and a second policy may permit (A and C). A different user may choose to use the policy that (A and B and C) are all required. Anastasis imposes no limit on the number of policies in a recovery document, or the set of providers or escrow methods involved in guarding a user’s secret. Weak adversaries must not be able to deduce information about a user’s recovery document (except for its length, which may be exposed to an adversary which monitors the user’s network traffic).

13.1. Anastasis DB-Schema


13.2. Anastasis Cryptography

When a user needs to interact with Anastasis, the system first derives some key material, but not the master secret, from the user’s identifier using different HKDFs. These HKDFs are salted using the respective escrow provider’s server salt, which ensures that the accounts for the same user cannot be easily correlated across the various Anastasis servers.

Each Anastasis server uses an EdDSA account key to identify the account of the user. The account private key is derived from the user’s identifier using a computationally expensive cryptographic hash function. Using an expensive hash algorithm is assumed to make it infeasible for a weak adversary to determine account keys by brute force (without knowing the user’s identifier). However, it is assumed that a strong adversary performing a targeted attack can compute the account key pair.

The public account key is Crockford base32-encoded in the URI to identify the account, and used to sign requests. These signatures are also provided in base32-encoding and transmitted using the HTTP header “Anastasis-Account-Signature”.

When confidential data is uploaded to an Anastasis server, the respective payload is encrypted using AES-GCM with a symmetric key and initialization vector derived from the identifier and a high-entropy nonce. The nonce and the GCM tag are prepended to the ciphertext before being uploaded to the Anastasis server. This is done whenever confidential data is stored with the server.

The core secret of the user is (AES) encrypted using a symmetric master key. Recovering this master key requires the user to satisfy a particular policy. Policies specify a set of escrow methods, each of which leads the user to a key share. Combining those key shares (by hashing) allows the user to obtain a policy key, which can be used to decrypt the master key. There can be many policies, satisfying any of these will allow the user to recover the master key. A recovery document contains the encrypted core secret, a set of escrow methods and a set of policies.

13.3. Key derivations

EdDSA and ECDHE public keys are always points on Curve25519 and represented using the standard 256 bit Ed25519 compact format. The binary representation is converted to Crockford Base32 when transmitted inside JSON or as part of URLs.

To start, a user provides their private, unique and unforgettable identifier as a seed to identify their account. For example, this could be a social security number together with their full name. Specifics may depend on the cultural context, in this document we will simply refer to this information as the identifier.

This identifier will be first hashed with SCrypt, to provide a kdf_id which will be used to derive other keys later. The Hash must also include the respective server_salt. This also ensures that the kdf_id is different on each server. The use of SCrypt and the respective server_salt is intended to make it difficult to brute-force kdf_id values and help protect user’s privacy. Also this ensures that the kdf_ids on every server differs. However, we do not assume that the identifier or the kdf_id cannot be determined by an adversary performing a targeted attack, as a user’s identifier is likely to always be known to state actors and may likely also be available to other actors.

kdf_id := SCrypt( identifier, server_salt, keysize )

identifier: The secret defined from the user beforehand.

server_salt: The salt from the Server

keysize: The desired output size of the KDF, here 32 bytes.

13.3.1. Verification

For users to authorize “policy” operations we need an EdDSA key pair. As we cannot assure that the corresponding private key is truly secret, such policy operations must never be destructive: Should an adversary learn the private key, they could access (and with the kdf_id decrypt) the user’s policy (but not the core secret), or upload a new version of the encrypted recovery document (but not delete an existing version).

For the generation of the private key we use the kdf_id as the entropy source, hash it to derive a base secret which will then be processed to fit the requirements for EdDSA private keys. From the private key we can then generate the corresponding public key. Here, “ver” is used as a salt for the HKDF to ensure that the result differs from other cases where we hash kdf_id.

ver_secret:= HKDF(kdf_id, "ver", keysize)
eddsa_priv := eddsa_d_to_a(ver_secret)
eddsa_pub := get_EdDSA_Pub(eddsa_priv)

HKDF(): The HKDF-function uses to phases: First we use HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion phase.

kdf_id: Hashed identifier.

key_size: Size of the output, here 32 bytes.

ver_secret: Derived key from the kdf_id, serves as intermediate step for the generation of the private key

eddsa_d_to_a(): Function which converts the ver_key to a valid EdDSA private key. Specifically, assuming the value eddsa_priv is in a 32-byte array “digest”, the function clears and sets certain bits as follows:

digest[0] = (digest[0] & 0x7f) | 0x40;
digest[31] &= 0xf8;

eddsa_priv: The generated EdDSA private key.

eddsa_pub: The generated EdDSA public key.

13.3.2. Encryption

For symmetric encryption of data we use AES256-GCM. For this we need a symmetric key and an initialization vector (IV). To ensure that the symmetric key changes for each encryption operation, we compute the key material using an HKDF over a nonce and the kdf_id.

(iv,key) := HKDF(kdf_id, nonce, keysize + ivsize)

HKDF(): The HKDF-function uses to phases: First we use HMAC-SHA512 for the extraction phase, then HMAC-SHA256 is used for expansion phase.

kdf_id: Hashed identifier

keysize: Size of the AES symmetric key, here 32 bytes

ivsize: Size of the AES GCM IV, here 12 bytes

prekey: Original key material.

nonce: 32-byte nonce, must never match “ver” (which it cannot as the length is different). Of course, we must avoid key reuse. So, we have to use different nonces to get different keys and ivs (see below).

key: Symmetric key which is later used to encrypt the documents with AES256-GCM.

iv: IV which will be used for AES-GCM

13.4. Key Usage

The keys we have generated are then used to encrypt the recovery document and the key_share of the user.

13.4.1. Encryption

Before every encryption a 32-byte nonce is generated. From this the symmetric key is computed as described above. We use AES256-GCM for the encryption of the recovery document and the key_share. To ensure that the key derivation for the encryption of the recovery document differs fundamentally from that of an individual key share, we use different salts (“erd” and “eks” respectively).

(iv0, key0) = HKDF(key_id, nonce0, "erd", keysize + ivsize)
(encrypted_recovery_document, aes_gcm_tag) = AES256_GCM(recovery_document, key0, iv0)
(iv_i, key_i) = HKDF(key_id, nonce_i, "eks", [optional data], keysize + ivsize)
(encrypted_key_share_i, aes_gcm_tag_i) = AES256_GCM(key_share_i, key_i, iv_i)

encrypted_recovery_document: The encrypted recovery document which contains the escrow methods, policies and the encrypted core secret.

nonce0: Nonce which is used to generate key0 and iv0 which are used for the encryption of the recovery document. Nonce must contain the string “ERD”.

optional data: Key material that optionally is contributed from the authentication method to further obfuscate the key share from the escrow provider.

encrypted_key_share_i: The encrypted key_share which the escrow provider must release upon successful authentication. Here, i must be a positive number used to iterate over the various key shares used for the various escrow methods at the various providers.

nonce_i: Nonce which is used to generate key_i and iv_i which are used for the encryption of the key share. i must be the same number as specified above for encrypted_key_share_i. Nonce must contain the string “EKS” plus the according i.

13.4.2. Signatures

The EdDSA keys are used to sign the data sent from the client to the server. Everything the client sends to server is signed. The following algorithm is equivalent for Anastasis-Policy-Signature.

(anastasis-account-signature) = eddsa_sign(h_body, eddsa_priv)
ver_res = eddsa_verifiy(h_body, anastasis-account-signature, eddsa_pub)

anastasis-account-signature: Signature over the SHA-512 hash of the body using the purpose code TALER_SIGNATURE_ANASTASIS_POLICY_UPLOAD (1400) (see GNUnet EdDSA signature API for the use of purpose)

h_body: The hashed body.

ver_res: A boolean value. True: Signature verification passed, False: Signature verification failed.

When requesting policy downloads, the client must also provide a signature:

(anastasis-account-signature) = eddsa_sign(version, eddsa_priv)
ver_res = eddsa_verifiy(version, anastasis-account-signature, eddsa_pub)

anastasis-account-signature: Signature over the SHA-512 hash of the body using the purpose code TALER_SIGNATURE_ANASTASIS_POLICY_DOWNLOAD (1401) (see GNUnet EdDSA signature API for the use of purpose)

version: The version requested as a 64-bit integer, 2^64-1 for the “latest version”.

ver_res: A boolean value. True: Signature verification passed, False: Signature verification failed.

13.5. Availability Considerations

Anastasis considers two main threats against availability. First, the Anastasis server operators must be protected against denial-of-service attacks where an adversary attempts to exhaust operator’s resources. The API protects against these attacks by allowing operators to set fees for all operations. Furthermore, all data stored comes with an expiration logic, so an attacker cannot force servers to store data indefinitively.

A second availability issue arises from strong adversaries that may be able to compute the account keys of some user. While we assume that such an adversary cannot successfully authenticate against the truth, the account key does inherently enable these adversaries to upload a new policy for the account. This cannot be prevented, as the legitimate user must be able to set or change a policy using only the account key. To ensure that an adversary cannot exploit this, policy uploads first of all never delete existing policies, but merely create another version. This way, even if an adversary uploads a malicious policy, a user can still retrieve an older version of the policy to recover access to their data. This append-only storage for policies still leaves a strong adversary with the option of uploading many policies to exhaust the Anastasis server’s capacity. We limit this attack by requiring a policy upload to include a reference to a payment identifier from a payment made by the user. Thus, a policy upload requires both knowledge of the identity and making a payment. This effectively prevents and adversary from using the append-only policy storage from exhausting Anastasis server capacity.

13.6. Anastasis API

13.6.1. Obtain salt

GET /salt

Obtain the salt used by the escrow provider. Different providers will use different high-entropy salt values. The resulting provider salt is then used in various operations to ensure cryptographic operations differ by provider. A provider must never change its salt value.


Returns a SaltResponse.

interface SaltResponse {
  // salt value, at least 128 bits of entropy
  server_salt: string;

13.6.2. Receiving Terms of Service

GET /terms

Obtain the terms of service provided by the escrow provider.


Returns an EscrowTermsOfServiceResponse.

interface EscrowTermsOfServiceResponse {

  // minimum supported protocol version
  min_version: number;

  // maximum supported protocol version
  max_version: number;

  // supported authentication methods
  auth_methods: AuthenticationMethod[];

  // Payment required to maintain an account to store policy documents for a month.
  // Users can pay more, in which case the storage time will go up proportionally.
  monthly_account_fee: Amount;

  // Amount required per policy upload. Note that the amount is NOT charged additionally
  // to the monthly_storage_fee. Instead, when a payment is made, the amount is
  // divided by the policy_upload_fee (and rounded down) to determine how many
  // uploads can be made under the associated **payment identifier**.
  policy_upload_ratio: Amount;

  // maximum policy upload size supported
  policy_size_limit_in_bytes: number;

  // maximum truth upload size supported
  truth_size_limit_in_bytes: number;

  // how long until the service expires deposited truth
  // (unless refreshed via another POST)?
  truth_expiration: RelativeTime;

  // Payment required to upload truth.  To be paid per upload.
  truth_upload_fee: Amount;

  // Limit on the liability that the provider is offering with
  // respect to the services provided.
  liability_limit: Amount;

  // HTML text describing the terms of service in legalese.
  // May include placeholders like "${truth_upload_fee}" to
  // reference entries in this response.
  tos: string;

interface AuthenticationMethod {
  // name of the authentication method
  name: string;

  // Fee for accessing truth using this method
  usage_fee: Amount;


13.6.3. Manage policy

This API is used by the Anastasis client to deposit or request encrypted recovery documents with the escrow provider. Generally, a client will deposit the same encrypted recovery document with each escrow provider, but provide different truth to each escrow provider.

Operations by the client are identified and authorized by $ACCOUNT_PUB, which should be kept secret from third parties. $ACCOUNT_PUB should be an account public key using the Crockford base32-encoding.

In the following, UUID is always defined and used according to RFC 4122.

GET /policy/$ACCOUNT_PUB[?version=$NUMBER]

Get the customer’s encrypted recovery document. If “version” is not specified, the server returns the latest available version. If “version” is specified, returns the policy with the respective “version”. The response must begin with the nonce and an AES-GCM tag and continue with the ciphertext. Once decrypted, the plaintext is expected to contain:

  • the escrow policy
  • the separately encrypted master public key

Note that the key shares required to decrypt the master public key are not included, as for this the client needs to obtain authorization. The policy does provide sufficient information for the client to determine how to authorize requests for truth.

The client MAY provide an “If-None-Match” header with an Etag. In that case, the server MUST additionally respond with an “304” status code in case the resource matches the provided Etag.

Status Codes

Anastasis-Version: $NUMBER — The server must return actual version of the encrypted recovery document via this header. If the client specified a version number in the header of the request, the server must return that version. If the client did not specify a version in the request, the server returns latest version of the EncryptedRecoveryDocument.

Etag: Set by the server to the Base32-encoded SHA512 hash of the body. Used for caching and to prevent redundancies. The server MUST send the Etag if the status code is 200 OK.

If-None-Match: If this is not the very first request of the client, this contains the Etag-value which the client has reveived before from the server. The client SHOULD send this header with every request (except for the first request) to avoid unnecessary downloads.

Anastasis-Account-Signature: The client must provide Base-32 encoded EdDSA signature over hash of body with $ACCOUNT_PRIV, affirming desire to download the requested encrypted recovery document. The purpose used MUST be TALER_SIGNATURE_ANASTASIS_POLICY_DOWNLOAD (1401).


Upload a new version of the customer’s encrypted recovery document. While the document’s structure is described in JSON below, the upload should just be the bytestream of the raw data (i.e. 32 bytes nonce followed by 16 bytes tag followed by the encrypted document). If request has been seen before, the server should do nothing, and otherwise store the new version. The body must begin with a nonce, an AES-GCM tag and continue with the ciphertext. The format is the same as specified for the response of the GET method. The Anastasis server cannot fully validate the format, but MAY impose minimum and maximum size limits.

Status Codes
  • 204 No Content – The encrypted recovery document was accepted and stored. “Anastasis-Version” and “Anastasis-UUID” headers incidate what version and UUID was assigned to this encrypted recovery document upload by the server.
  • 304 Not modified – The same encrypted recovery document was previously accepted and stored. “Anastasis-Version” header incidates what version was previously assigned to this encrypted recovery document.
  • 400 Bad request – The $ACCOUNT_PUB is not an EdDSA public key or mandatory headers are missing. The response body MUST elaborate on the error using a Taler error code in the typical JSON encoding.
  • 402 Payment Required – The account’s balance is too low for the specified operation. See the Taler payment protocol specification for how to pay. The response body MAY provide alternative means for payment.
  • 403 Forbidden – The required account signature was invalid. The response body may elaborate on the error.
  • 409 Conflict – The If-Match Etag does not match the latest prior version known to the server.
  • 413 Request Entity Too Large – The upload is too large or too small. The response body may elaborate on the error.
If-Match: Unless the client expects to upload the first encrypted recovery document to this account, the client
SHOULD provide an Etag matching the latest version already known to the server. If this header is present, the server MUST refuse the upload if the latest known version prior to this upload does not match the given Etag.
If-None-Match: This header MUST be present and set to the SHA512 hash (Etag) of the body by the client.
The client SHOULD also set the “Expect: 100-Continue” header and wait for “100 continue” before uploading the body. The server MUST use the Etag to check whether it already knows the encrypted recovery document that is about to be uploaded. The server MUST refuse the upload with a “304” status code if the Etag matches the latest version already known to the server.

Anastasis-Policy-Signature: The client must provide Base-32 encoded EdDSA signature over hash of body with $ACCOUNT_PRIV, affirming desire to upload an encrypted recovery document.

Payment-Identifier: Base-32 encoded 32-byte payment identifier that was included in a previous payment (see 402 status code). Used to allow the server to check that the client paid for the upload (to protect the server against DoS attacks) and that the client knows a real secret of financial value (as the kdf_id might be known to an attacker). If this header is missing in the client’s request (or the associated payment has exceeded the upload limit), the server must return a 402 response. When making payments, the server must include a fresh, randomly-generated payment-identifier in the payment request.


interface EncryptedRecoveryDocument {
  // Nonce used to compute the (iv,key) pair for encryption of the
  // encrypted_compressed_recovery_document.
  nonce: [32]; //bytearray

  // Authentication tag
  aes_gcm_tag: [16]; //bytearray

  // Variable-size encrypted recovery document. After decryption,
  // this contains a gzip compressed JSON-encoded RecoveryDocument.
  // The nonce of the HKDF for this encryption must include the
  // string "ERD".
  encrypted_compressed_recovery_document: []; //bytearray of undefined length

interface RecoveryDocument {
  // Account identifier at backup provider, AES-encrypted with
  // the (symmetric) master_key, i.e. an URL
  // https://sync.taler.net/$BACKUP_ID and
  // a private key to decrypt the backup.  Anastasis is oblivious
  // to the details of how this is ultimately encoded.
  backup_account: []; //bytearray of undefined length

  // List of escrow providers and selected authentication method
  methods: EscrowMethod[];

  // List of possible decryption policies
  policy: DecryptionPolicy[];

interface EscrowMethod {
  // URL of the escrow provider (including possibly this Anastasis server)
  provider_url : string;

  // Name of the escrow method (e.g. security question, SMS etc.)
  escrow_method: string;

  // UUID of the escrow method (see /truth/ API below).
  uuid: string;

  // Key used to encrypt the Truth this EscrowMethod is related to.
  // Client has to provide this key to the server when using /truth/
  truth_encryption_key: [32]; //bytearray

  // Salt used to encrypt the truth on the Anastasis server.
  truth_salt: [32]; //bytearray

  // The challenge to give to the user (i.e. the security question
  // if this is challenge-response).
  // (Q: as string in base32 encoding?)
  // (Q: what is the mime-type of this value?)
  // For some methods, this value may be absent.
  // The plaintext challenge is not revealed to the
  // Anastasis server.
  challenge: []; //bytearray of undefined length

interface DecryptionPolicy {
  // Salt included to encrypt master key share when
  // using this decryption policy.
  policy_salt: [32]; //bytearray

  // Master key, AES-encrypted with key derived from
  // salt and keyshares revealed by the following list of
  // escrow methods identified by UUID.
  encrypted_master_key: [32]; //bytearray

  // List of escrow methods identified by their uuid.
  uuid: string[];


13.6.4. Managing truth

This API is used by the Anastasis client to deposit truth or request a (encrypted) key share with the escrow provider.

An escrow method specifies an Anastasis provider and how the user should authorize themself. The truth API allows the user to provide the (encrypted) key share to the respective escrow provider, as well as auxiliary data required for such an respective escrow method.

An Anastasis-server may store truth for free for a certain time period, or charge per truth operation using GNU Taler.

POST /truth/$UUID

Upload a TruthUploadRequest-Object according to the policy the client created before (see RecoveryDocument). If request has been seen before, the server should do nothing, and otherwise store the new object.

Status Codes
  • 204 No content – Truth stored successfully.
  • 304 Not modified – The same truth was previously accepted and stored under this UUID. The Anastasis server must still update the expiration time for the truth when returning this response code.
  • 402 Payment Required – This server requires payment to store truth per item. See the Taler payment protocol specification for how to pay. The response body MAY provide alternative means for payment.
  • 409 Conflict – The server already has some truth stored under this UUID. The client should check that it is generating UUIDs with enough entropy.
  • 412 Precondition Failed – The selected authentication method is not supported on this provider.


interface TruthUploadRequest {
  // Contains the information of an interface EncryptedKeyShare, but simply
  // as one binary block (in Crockford Base32 encoding for JSON).
  key_share_data: []; //bytearray

  // Key share method, i.e. "security question", "SMS", "e-mail", ...
  method: string;

  // Nonce used to compute the (iv,key) pair for encryption of the
  // encrypted_truth.
  nonce: [32]; //bytearray

  // Authentication tag of encrypted_truth
  aes_gcm_tag: [16]; //bytearray

  // Variable-size truth. After decryption,
  // this contains the ground truth, i.e. H(challenge answer),
  // phone number, e-mail address, picture, fingerprint, ...
  // **base32 encoded**.
  // The nonce of the HKDF for this encryption must include the
  // string "ECT".
  encrypted_truth: [80]; //bytearray

  // mime type of truth, i.e. text/ascii, image/jpeg, etc.
  truth_mime: string;

GET /truth/$UUID[?response=$RESPONSE]

Get the stored encrypted key share. If $RESPONSE is specified by the client, the server checks if $RESPONSE matches the expected response specified before within the TruthUploadRequest (see encrypted_truth). Also, the user has to provide the correct truth_encryption_key with every get request (see below). When $RESPONSE is correct, the server responses with the encrypted key share. The encrypted key share is returned simply as a byte array and not in JSON format.

Status Codes
  • 200 OKEncryptedKeyShare is returned in body (in binary).
  • 202 Accepted – The escrow provider will respond out-of-band (i.e. SMS). The body may contain human-readable instructions on next steps.
  • 303 See Other – The provider redirects for authentication (i.e. video identification/WebRTC). If the client is not a browser, it should launch a browser at the URL given in the “Location” header and allow the user to re-try the operation after successful authorization.
  • 402 Payment Required – The service requires payment for access to truth. See the Taler payment protocol specification for how to pay. The response body MAY provide alternative means for payment.
  • 403 Forbidden – The server requires a valid “response” to the challenge associated with the UUID.
  • 404 Not Found – The server does not know any truth under the given UUID.
  • 503 Service Unavailable – Server is out of Service.

Truth-Decryption-Key: Key used to encrypt the truth (see encrypted_truth within TruthUploadRequest) and which has to provided by the user. The key is stored with the according EscrowMethod. The server needs this key to get the info out of TruthUploadRequest needed to verify the $RESPONSE.


interface EncryptedKeyShare {
  // Nonce used to compute the decryption (iv,key) pair.
  nonce_i: [32]; //bytearray

  // Authentication tag
  aes_gcm_tag_i: [16]; //bytearray

  // Encrypted key-share in base32 encoding.
  // After decryption, this yields a KeyShare.  Note that
  // the KeyShare MUST be encoded as a fixed-size binary
  // block (instead of in JSON encoding).
  // HKDF for the key generation must include the
  // string "eks" as salt.
  // Depending on the method,
  // the HKDF may additionally include
  // bits from the response (i.e. some hash over the
  // answer to the security question)
  encrypted_key_share_i: [32]; //bytearray

interface KeyShare {
  // Key material to concatenate with policy_salt and KDF to derive
  // the key to decrypt the master key.
  key_share: [32]; //bytearray

  // Signature over method, uuid, and key_share.
  account_sig: EddsaSignature;


13.7. Authentication Methods

This section describes the supported authentication methods in detail.

13.7.1. SMS (sms)

Sends an SMS with a code to the users phone. The must send this code back with his request (see $RESPONSE under ‘Managing truth’). If the transmitted code is correct, the server responses with the requested encrypted key share. FIXME: details!

13.7.2. Video identification (vid)

Requires the user to identify via video-call. The user is expected to delete all metadata revealing information about him/her from the images before uploading them. Since the respective images must be passed on to the video identification service in the event of password recovery, it must be ensured that no further information about the user can be derived from them. FIXME: details!

13.7.3. Security question (qa)

Asks the user a security question. The user sends back a hash over the answer. If the hash value matches with the one the server is expecting, the server answers with the requested encrypted key share. A different hash function over the same security answer is used to provide optional data for the decryption of the (encrypted) key share.

13.7.4. Post-Indent (post)

Physical address verification via snail mail. FIXME: details!