Quasor

Quasor: A High-Security AEAD

Version 6.0

1. Introduction and Goals

Quasor is a high-security Authenticated Encryption with Associated Data (AEAD) scheme designed for modern applications where robustness and defense-in-depth are paramount. It is built on a Duplex Sponge construction using SHAKE256 and incorporates several advanced features to provide strong protection against both implementation errors and sophisticated attacks.

The primary design goals achieved in this version are:

• Post-Quantum Resistance: The underlying sponge construction uses a 1600-bit permutation, offering a high security margin against quantum attacks.
• Password-Based Key Derivation: Uses the memory-hard Argon2id function to protect against brute-force attacks on user-provided passwords.
• Nonce-Misuse Resistance: Implements a Synthetic Initialization Vector (SIV) mechanism, which prevents catastrophic key-reuse failures in the event of a nonce collision.
• Forward Secrecy: Integrates an automatic rekeying mechanism to ensure that a compromised key cannot be used to decrypt past messages.
• Secure Memory Management: Employs mechanisms to securely zero out sensitive key material in memory when it is no longer needed.

2. Cryptographic Primitives

• Sponge / Extendable-Output Function (XOF): SHAKE256 (from the SHA-3 family).
• Keyed Hash / Nonce Derivation: BLAKE3 (parallelized for performance).
• Password-Based Key Derivation Function (KDF): Argon2id (memory-hard).

3. Key Derivation Process

The master key K for the cipher is derived from a user-provided password and a unique salt using Argon2id.

1. Inputs: A user password (variable length) and a unique salt (minimum 8 bytes).
2. Hashing: The Argon2id function is called with its default secure parameters (as of v0.5) to produce a 32-byte (256-bit) master key K.
3. Security: This process is intentionally slow and memory-intensive to make offline brute-force and dictionary attacks computationally infeasible.

4. Encryption Process

Inputs:

• A Quasor instance containing the master key K.
• Plaintext P.
• Associated Data A.

Procedure:

1. Nonce Derivation (SIV):

   a. A 128-bit nonce N is derived by computing the keyed hash of the associated data and the plaintext using a secure, unambiguous serialization.

   b. The exact structure to be hashed is: len(A)

   A

   len(P)

   P, where len() is the length in bytes, encoded as a 64-bit little-endian integer.

   c. For large inputs, the hashing of P is automatically parallelized using Rayon for high performance.

2. Initialization:

   a. A new SHAKE256 sponge instance is initialized.

   b. The master key K, the derived nonce N, and the associated data A are absorbed into the sponge.

3. Encryption, Duplexing, and Rekeying:

   a. The plaintext P is processed sequentially in chunks of REKEY_INTERVAL size (1 MiB).

   b. For each block within a chunk, a keystream is squeezed from the sponge and XORed with the plaintext to produce ciphertext. The original plaintext block is then absorbed back into the sponge’s state.

   c. After each 1 MiB chunk is processed (except the last), a rekeying step is performed: 32 bytes are squeezed from the sponge to form an ephemeral key, which is then immediately absorbed back into the state. This provides forward secrecy.

4. Tag Generation:

   a. After all plaintext has been processed, a 32-byte authentication tag T is squeezed from the sponge’s final state.

Outputs:

• Ciphertext C
• Authentication Tag T
• Derived Nonce N (must be stored with the ciphertext)

5. Decryption Process

Inputs:

• A Quasor instance containing the master key K.
• Nonce N (16 bytes).
• Ciphertext C.
• Associated Data A.
• Authentication Tag T.

Procedure:

1. Initialization & Decryption: The decryption process mirrors the encryption process exactly: the sponge is initialized with K, N, and A, and the ciphertext is processed sequentially to reconstruct the plaintext, with identical rekeying steps performed along the way.

2. Tag Verification:

   a. After all ciphertext is processed, an expected tag T’ is squeezed from the sponge’s final state.

   b. The received tag T must be compared to the computed tag T’ using a constant-time equality function. This is a critical step to prevent timing side-channel attacks. If they do not match, the process aborts, and an error is returned.

3. Nonce Verification:

   a. If the tag is valid, the SIV nonce is re-derived using the newly decrypted plaintext P and the same length-prefixed serialization as in encryption.

   b. This re-derived nonce N’ is compared to the received nonce N. If they do not match, the process aborts, and an error is returned. This final check ensures the integrity of the entire message.

Output:

• Plaintext P (on success) or an authentication error.

6. Design Rationale and Security Considerations

• Constant-Time Operations: All comparisons of cryptographic secrets (specifically, the authentication tag and the SIV nonce) must be performed in constant time. This mitigates timing side-channel attacks, where an attacker could infer information about secrets by measuring the time it takes for a comparison to complete.
• Sequential Duplexing: The core encryption/decryption loop is intentionally sequential. While parallelizing this step is possible in some sponge modes, it would break the specific duplex construction used here, which relies on a sequential state to ensure security. The performance gain was not worth the security trade-off. Parallelism is safely used in the SIV nonce derivation step, where it provides a significant speedup for large messages without compromising the core cipher.
• Memory-Hard KDF: Using Argon2id makes Quasor highly resistant to password cracking attempts. It is the recommended choice for any application where the encryption key is derived from a user-provided password.
• Nonce-Misuse Resistance (SIV): By deriving the nonce deterministically from the message content, Quasor prevents the catastrophic key-reuse vulnerabilities that plague many other AEADs. If a user accidentally encrypts the same message twice, the same nonce will be generated, resulting in the same ciphertext. This reveals that a message was repeated but does not compromise the security of other messages.
• Forward Secrecy (Rekeying): The automatic rekeying mechanism ensures that a compromise of the cipher’s state at any given time does not compromise previously encrypted data. This makes Quasor suitable for long-lived, secure communication sessions.
• Secure Memory: The Quasor struct and its internal states are designed to use the zeroize crate, which securely overwrites sensitive key material in memory as soon as it goes out of scope, protecting against certain types of memory-scraping attacks.

This site is open source. Improve this page.