# Appendix: cryptography

> Palladin documentation · 1.0 · EN · 2026-10-25


This appendix contains technical details. See [Data and keys](/docs/whitepaper/keys) for an introduction. VK means Vault Key and DEK means Data Encryption Key.

## Cryptographic suite

| Operation | Mechanism |
| --- | --- |
| Password derivation | Argon2id: 32 MiB memory, 2 iterations, 1 lane, 32-byte account root; profile `identity-argon2id-password-v1`. |
| Separate authentication and Master Key | HKDF-SHA256 derives two keys from the account root, using distinct purpose labels and the account ID. |
| Account private-key protection | XSalsa20-Poly1305. Recovery uses a separate Argon2id profile with 19 MiB memory. |
| Vault content encryption and symmetric key wrapping | XChaCha20-Poly1305, suite `palladin-vault-xchacha-v1`. |
| Asymmetric key delivery | X25519 sealed package, suite `palladin-x25519-sealed-box-v1`. |
| Agent identity signatures | Ed25519. |
| Symmetric VK / DEK | Random 32-byte keys generated client-side. |

Algorithm names alone do not specify a protocol. Implementations must use the exact format, signature domains, encoding, nonce rules, and canonicalization from the versioned contract. Do not implement cryptography from this summary alone.

## Verify before use

1. Read the explicit suite identifier and protocol version; reject unsupported variants.
2. Check structure and size bounds before processing.
3. Verify signatures and required commitments.
4. Compare organization, vault, principal, grant, revisions, epochs, and key versions against independent authoritative context.
5. Open material only within the permitted boundary and stop on authentication failure.

## Implementation compatibility

Shared fixtures and test vectors should verify client/backend compatibility. Negative tests must cover substituted recipients, different vaults, stale revisions, wrong epochs, and modified ciphertext. A library decrypting its own output is insufficient evidence.