ChaCha20BLAKE2b 2.0.1

ChaCha20-BLAKE2b

Committing ChaCha20-BLAKE2b, XChaCha20-BLAKE2b, and XChaCha20-BLAKE2b-SIV AEAD implementations using libsodium.

Features

This library does several things for you:

• Derives a 256-bit encryption key and 512-bit MAC key based on the key and nonce.
• Supports additional data in the calculation of the authentication tag, unlike most Encrypt-then-MAC implementations.
• Appends the authentication tag to the ciphertext.
• Compares the authentication tags in constant time during decryption and only returns plaintext if they match.
• Offers access to an SIV implementation that does not take a nonce.

Justification

The popular AEADs in use today, such as (X)ChaCha20-Poly1305, AES-GCM, AES-GCM-SIV, XSalsa20-Poly1305, AES-OCB, and so on, are not key or message committing. This means it is possible to decrypt a ciphertext using multiple keys without an authentication error, which can lead to partitioning oracle attacks and deanonymisation in certain online scenarios. Furthermore, if an attacker knows the key, then they can find other messages that have the same tag.

This library was created because there are currently no standardised committing AEAD schemes, adding the commitment property to a non-committing AEAD requires using a MAC, and Encrypt-then-MAC offers improved security guarantees, both in terms of the longer authentication tag and commitment properties.

Finally, (X)ChaCha20-BLAKE2b is the ideal combination for an Encrypt-then-MAC scheme because:

1. ChaCha20 has a higher security margin than AES, performs well on older devices, and runs in constant time, unlike AES.
2. BLAKE2b is as real-world secure as SHA3 whilst being considerably faster. It relies on essentially the same core algorithm as BLAKE, which received a significant amount of cryptanalysis, even more than Keccak (the SHA3 finalist), as part of the SHA3 competition.

Installation

1. Install the Sodium.Core NuGet package in Visual Studio.
2. Download the latest release.
3. Move the downloaded .dll file into your Visual Studio project folder.
4. Click on the Project tab and Add Project Reference... in Visual Studio.
5. Go to Browse, click the Browse button, and select the downloaded .dll file.
6. Add using ChaCha20BLAKE2; to the top of each code file that will use the library.

Requirements

Note that the libsodium library requires the Visual C++ Redistributable for Visual Studio 2015-2019 to work on Windows. If you want your program to be portable, then you must keep the relevant (x86 or x64) vcruntime140.dll file in the same folder as your executable on Windows.

Usage

ChaCha20-BLAKE2b

⚠️WARNING: Never reuse a nonce with the same key.

const string message = "This is a test.";
const string version = "application v2.0.0";

// The message could be a file
byte[] message = Encoding.UTF8.GetBytes(message);

// The nonce should be a counter that gets incremented for each message encrypted using the same key
byte[] nonce = new byte[ChaCha20BLAKE2b.NonceSize];

// The key can be randomly generated using a CSPRNG or derived using a KDF (e.g. Argon2, HKDF, etc)
byte[] key = SodiumCore.GetRandomBytes(ChaCha20BLAKE2b.KeySize);

// The additional data can be null but is ideal for file headers, version numbers, timestamps, etc
byte[] additionalData = Encoding.UTF8.GetBytes(version);

// Encrypt the message and use a 256-bit authentication tag
byte[] ciphertext = ChaCha20BLAKE2b.Encrypt(message, nonce, key, additionalData, TagLength.BLAKE2b256);

// Decrypt the ciphertext
byte[] plaintext = ChaCha20BLAKE2b.Decrypt(ciphertext, nonce, key, additionalData, TagLength.BLAKE2b256);

XChaCha20-BLAKE2b

⚠️WARNING: Never reuse a nonce with the same key.

const string message = "This is a test.";
const string version = "application v2.0.0";

// The message could be a file
byte[] message = Encoding.UTF8.GetBytes(message);

// The nonce can be random. Increment or randomly generate the nonce for each message encrypted using the same key
byte[] nonce = SodiumCore.GetRandomBytes(XChaCha20BLAKE2b.NonceSize);

// The key can be randomly generated using a CSPRNG or derived using a KDF (e.g. Argon2, HKDF, etc)
byte[] key = SodiumCore.GetRandomBytes(XChaCha20BLAKE2b.KeySize);

// The additional data can be null but is ideal for file headers, version numbers, timestamps, etc
byte[] additionalData = Encoding.UTF8.GetBytes(version);

// Encrypt the message and use a 512-bit authentication tag
byte[] ciphertext = XChaCha20BLAKE2b.Encrypt(message, nonce, key, additionalData, TagLength.BLAKE2b512);

// Decrypt the ciphertext
byte[] plaintext = XChaCha20BLAKE2b.Decrypt(ciphertext, nonce, key, additionalData, TagLength.BLAKE2b512);

XChaCha20-BLAKE2b-SIV

⚠️WARNING: Never reuse a key. As a precaution, you can use at least 16 bytes of unique, random data as part of the additional data to act as a nonce.

const string filePath = "C:\\Users\\samuel-lucas6\\Pictures\\test.jpg";

// The message does not have to be a file
byte[] message = File.ReadAllBytes(filePath);

// The key can be randomly generated using a CSPRNG or derived using a KDF (e.g. Argon2, HKDF, etc)
byte[] key = SodiumCore.GetRandomBytes(XChaCha20BLAKE2bSIV.KeySize);

// The additional data can be null, used as a nonce, and/or used for file headers, version numbers, timestamps, etc
byte[] additionalData = SodiumCore.GetRandomBytes(XChaCha20BLAKE2bSIV.KeySize / 2);

// Encrypt the message and use the default authentication tag length (256-bit)
byte[] ciphertext = XChaCha20BLAKE2bSIV.Encrypt(message, key, additionalData);

// Decrypt the ciphertext
byte[] plaintext = XChaCha20BLAKE2bSIV.Decrypt(ciphertext, key, additionalData);

Benchmarks

The following benchmarks were done using BenchmarkDotNet in a .NET 6 console application with 16 bytes of additional data and the default 256-bit tag size.

In sum, (X)ChaCha20-BLAKE2b is almost identical in speed to (X)ChaCha20-Poly1305 for 16-64 KiB messages, which is perfect since these are ideal chunk sizes for performing chunked encryption.

Chunked encryption should be preferred over encrypting large messages in one go because it reduces memory usage, allows earlier detection of corrupted chunks, may help reduce data loss, and reduces wiggle room for attacks in the case of popular AEADs (e.g. ChaCha20-Poly1305 and AES-GCM).

However, (X)ChaCha20-BLAKE2b is slower than (X)ChaCha20-Poly1305 for small and large messages. With that said, you should perform chunked encryption on large messages anyway, rendering that finding unimportant, and I would argue that the additional security makes this trade-off worthwhile in the case of small messages.

512-byte file

16.1 KiB file

31.6 KiB file

64.7 KiB file

129 KiB file

34.1 MiB file