Cryptography Specifications

Nen is built upon the following cryptographic primitives, carefully selected for their security, performance, and resistance to quantum attacks.

Key Encapsulation: ML-KEM (Kyber)

• Standard: FIPS 203
• Parameter Set: Kyber768 (Level 3 security, roughly equivalent to AES-192)
• Usage: Used to securely transmit a 32-byte shared secret across the network during the initial handshake.

Digital Signatures: ML-DSA (Dilithium)

• Standard: FIPS 204
• Parameter Set: Dilithium3 (Level 3 security)
• Usage: Used optionally by clients to sign their ML-KEM public key, proving identity to the server and preventing active Man-in-the-Middle (MitM) attacks.

Session keys

Nen does not run a separate KDF over the shared secret. The 32-byte secret produced by ML-KEM encapsulation is used directly as the ChaCha20-Poly1305 key. The server independently generates a separate random 32-byte HMAC key at handshake and returns it to the client alongside the ciphertext, so the encryption and authentication keys are distinct.

Symmetric Encryption: ChaCha20Poly1305

• Standard: RFC 8439
• Usage: An Authenticated Encryption with Associated Data (AEAD) cipher used to encrypt all JSON payloads. Chosen for its extreme performance in software (including WebAssembly) without relying on hardware AES acceleration. Each payload uses a fresh 12-byte nonce and carries a 16-byte Poly1305 tag — any tampering of the ciphertext fails decryption (ISO-4001).

Request Authentication: HMAC-SHA256

• Standard: FIPS 198-1 / FIPS 180-4
• Usage: Computes a message authentication code over the canonical string METHOD \n PATH \n TIMESTAMP \n NONCE (not over the ciphertext). This hot-path authentication is mandatory and extremely fast, protecting against forgery and replay before any decryption is attempted. PQC signatures are used only at the handshake, never per request.