Cryptography guidelines

All communication is designed with security and privacy in mind. Here we discuss some details that are generally true for the systems.


All cryptographic primitives and ciphertexts in the system are versioned in their context. This means seamless replacement of old ciphers or configurations may take place once the new cryptography has widespread support.

Symmetric cryptography

The AES symmetric encryption cipher is used with AES-SIV mode primarily. This mode is one of the most robust that is available, but it’s more resource demanding. The performance loss is relatively low because it is a clever construction of two other AES cipher modes: AES-CBC and AES-CTR. These two have support by the WebCrypto API in all relevant browsers. Using the high performance native modes, the performance of the AES-SIV construct is comparable to popular Javascript implementations of alternative ciphers like ChaCha or Salsa.

Noteworthy properties of AES-SIV:

  • It is an authenticated encryption, meaning it provides authenticity in addition to confidentiality.

  • The security it provides hardly degrades even when accidentally using repeating nonce values.

  • It is usable for key-wrapping.

  • It is a stream cipher. (even though it’s offline, meaning it needs two passes over a data)

Security value choices:

  • Nonce values are 12 bytes of CSPRNG or securely derived hash values.

  • We use keys that are equivalent to having 32 bytes of security for most AES modes. For AES-SIV this actually requires 64 bytes of length. These are usually generated with HKDF from a 32 byte true key.

Future improvements:

  • Once the WebCrypto API is updated, using AES-GCM-SIV would improve performance greatly.


Hashing is a multi-purpose cryptographical operation with many uses. Depending on the context we use SHA2 and SHA3 (Keccak). Where it is necessary for safety the digests are truncated to prevent length-extension-attacks.

Key derivation

To improve security and segment the confidentiality of encryption contexts, symmetric encryption keys are derived using HKDF. Key derivation is done with some high entropy constants and dynamic info/context value.

Asymmetric cryptography

For asymmetric encryption we use the popular 25519 curves for both signing and encryption. These curves have great security properties and their implementation is more straight forward than the NIST curves, making them favorable usually. Each account will have two 25519 curve pairs for encryption and signing. The ECDH facilitated by these curves allows two accounts to send each other messages securely. For identity assurance, the keypair used for signing is used to create a signature chain of the account’s public keyring. By securely encrypting a fingerprint of a peer account’s public singing key, their identity can be checked to be consistent. Utilizing this can prevent the servers from performing man-in-the-middle attacks.