XChaCha20-Poly1305

Purpose

XChaCha20-Poly1305 is an authenticated encryption with associated data (AEAD) scheme. It encrypts a plaintext message using a 256-bit key and 192-bit nonce (number used only once) before computing a tag over the ciphertext and associated data.

The associated data is useful for authenticating file headers, version numbers, timestamps, counters, and so on. It can be used to prevent confused deputy attacks and replay attacks. It is not encrypted nor part of the ciphertext. It must be reproduceable or stored somewhere for decryption to be possible.

For decryption, the tag is first verified for the given inputs, which detects tampering and incorrect parameters. If verification fails, an error is returned. Otherwise, the ciphertext is decrypted and plaintext is returned.

For encryption, the nonce MUST NOT be repeated or reused with the same key. You MUST increment or randomly generate the nonce for each plaintext message encrypted using the same key.

Unlike with ChaCha20-Poly1305, it is safe to randomly generate nonces with the same key. Nonces can be public and are typically manually prepended to the ciphertext.

Usage

Encrypt

Fills a span with ciphertext and an appended tag computed from a plaintext message, nonce, key, and optional associated data.

XChaCha20Poly1305.Encrypt(Span<byte> ciphertext, ReadOnlySpan<byte> plaintext, ReadOnlySpan<byte> nonce, ReadOnlySpan<byte> key, ReadOnlySpan<byte> associatedData = default)

Exceptions

ArgumentOutOfRangeException

ciphertext has a length not equal to plaintext.Length + TagSize.

ArgumentOutOfRangeException

nonce has a length not equal to NonceSize.

ArgumentOutOfRangeException

key has a length not equal to KeySize.

CryptographicException

Encryption failed.

Decrypt

Verifies that the tag appended to the ciphertext is correct for the given inputs. If verification fails, an exception is thrown. Otherwise, it fills a span with the decrypted ciphertext.

XChaCha20Poly1305.Decrypt(Span<byte> plaintext, ReadOnlySpan<byte> ciphertext, ReadOnlySpan<byte> nonce, ReadOnlySpan<byte> key, ReadOnlySpan<byte> associatedData = default)

Exceptions

ArgumentOutOfRangeException

plaintext has a length not equal to ciphertext.Length - TagSize.

ArgumentOutOfRangeException

ciphertext has a length less than TagSize.

ArgumentOutOfRangeException

nonce has a length not equal to NonceSize.

ArgumentOutOfRangeException

key has a length not equal to KeySize.

CryptographicException

Invalid authentication tag for the given inputs.

Constants

These are used for validation and/or save you defining your own constants.

public const int KeySize = 32;
public const int NonceSize = 24;
public const int TagSize = 16;

Notes

If you intend to feed multiple variable-length inputs into the associated data, beware of canonicalization attacks. Please read the Concat page for more information.

The key MUST be uniformly random. It can either be randomly generated or the output of a KDF. Furthermore, it SHOULD be rotated periodically (e.g. a different key per file).

Encrypting data in 16-64 KiB chunks instead of as a single plaintext message is recommended to keep memory usage low and detect corrupted chunks early. Unfortunately, it is difficult to get right. You MUST ensure that chunks cannot be:

1. Truncated

2. Removed

3. Reordered

4. Duplicated

1 and 2 can be accomplished by including the length of all the ciphertext chunks added together in the associated data of the first chunk. Alternatively, you can use the STREAM construction.

3 and 4 can be resolved by using a counter nonce (the initial nonce can be random) or by including the previous tag in the associated data of the next chunk.

If decryption fails midway through a stream due to tampering or corruption, erase the previous plaintext outputs from memory and/or disk and throw an error.

As a general rule, avoid compression before encryption. It can leak information and has been the cause of several attacks.

XChaCha20-Poly1305 is NOT key- or message-committing.

1. A ciphertext message can be decrypted under multiple keys without an error.

2. An attacker who knows the key can find different messages that lead to the same tag.

This can enable attacks in scenarios where keys can be adversarial. For example, when an attacker can submit a ciphertext encrypted using a password to a server that knows the encryption key (an oracle).

The best fix is to switch to Encrypt-then-MAC as outlined in that link.

Consider ChaCha20-Poly1305 if you do not need random nonces with the same key. For example, if you can use a counter nonce or rotate the key for each encryption operation. It is marginally more efficient.