> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kvelden.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cryptographic Primitives

> The exact algorithms and parameters Enclave uses — no marketing, just the spec.

## File encryption

| Property       | Value                                 |
| -------------- | ------------------------------------- |
| Algorithm      | AES-256-GCM                           |
| Key size       | 256 bits                              |
| IV size        | 96 bits (randomly generated per file) |
| Tag size       | 128 bits                              |
| Key derivation | HKDF-SHA256 from room KEK + file ID   |

## Key wrapping

| Property   | Value                                 |
| ---------- | ------------------------------------- |
| Algorithm  | AES-256-KW (RFC 3394)                 |
| Key size   | 256 bits                              |
| Applied to | DEK → KEK wrap, KEK → master key wrap |

For RSA-based KMS (Azure Key Vault with RSA-HSM):

| Property  | Value        |
| --------- | ------------ |
| Algorithm | RSA-OAEP-256 |
| Key size  | 4096 bits    |
| Hash      | SHA-256      |

## Zero-Knowledge key encapsulation (post-quantum hybrid)

In Zero-Knowledge and Zero-Knowledge Strict rooms, the room encryption key (REK) is
wrapped to each member's identity key using a **hybrid** key-encapsulation mechanism
that combines a classical and a post-quantum algorithm.

| Property              | Value                                                                     |
| --------------------- | ------------------------------------------------------------------------- |
| Scheme                | Hybrid **X25519 + ML-KEM-768**                                            |
| Post-quantum standard | NIST **FIPS 203** (ML-KEM), security category 3                           |
| Classical component   | X25519 (Curve25519 ECDH)                                                  |
| Combiner              | HKDF-SHA256 KDF-combiner (binds both ciphertexts + the ML-KEM public key) |
| Security              | IND-CCA secure if **either** component is unbroken                        |
| Applied to            | Wrapping the REK to each member's identity public key (grants, rotation)  |
| Identity public key   | 1216 bytes (x25519 32 B ‖ ml-kem-768 1184 B)                              |
| Symmetric tail        | HKDF-SHA256 → AES-256-GCM (unchanged)                                     |

Because the combiner never XORs and binds the ML-KEM ciphertext and public key, an
attacker who breaks only X25519 — or only ML-KEM — still cannot recover the wrapped
key. This protects against "harvest-now, decrypt-later": traffic captured today
stays confidential even against a future quantum computer. New enrolments use the
hybrid scheme; the wire format is versioned so legacy X25519 identities remain
readable. Client-side ML-KEM uses the audited `@noble/post-quantum` library; the
server never holds Zero-Knowledge key material.

## Audit log signatures

| Property        | Value                      |
| --------------- | -------------------------- |
| Algorithm       | Ed25519                    |
| Key storage     | Kvelden signing HSM        |
| Signature scope | Event payload + chain hash |
| Chain hash      | SHA-256 of previous entry  |

## TLS

| Property                         | Value                                                                            |
| -------------------------------- | -------------------------------------------------------------------------------- |
| Minimum version                  | TLS 1.2                                                                          |
| Preferred version                | TLS 1.3                                                                          |
| Cipher suites (TLS 1.3)          | TLS\_AES\_256\_GCM\_SHA384, TLS\_CHACHA20\_POLY1305\_SHA256                      |
| Cipher suites (TLS 1.2)          | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384                       |
| Key exchange (TLS 1.3, outbound) | Prefers the post-quantum hybrid **X25519MLKEM768** group, falling back to X25519 |
| Certificate                      | RSA-4096 or ECDSA P-384                                                          |

## Password hashing

| Property    | Value                         |
| ----------- | ----------------------------- |
| Algorithm   | Argon2id                      |
| Memory      | 64 MB                         |
| Iterations  | 3                             |
| Parallelism | 4                             |
| Output      | 32 bytes                      |
| Salt        | 16 bytes, random per password |

## Random number generation

All random values (IVs, DEKs, salts, tokens) are generated using the operating system's CSPRNG (`getrandom` on Linux, `BCryptGenRandom` on Windows).

## What we do not use

* MD5 or SHA-1 for any security purpose
* ECB mode for any block cipher
* RSA-PKCS1v1.5 for encryption (only RSA-OAEP)
* Static IVs or nonces
* Client-side session secrets stored in localStorage