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.
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.
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.
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.
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.