This appendix contains technical details. See Data and 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
- Read the explicit suite identifier and protocol version; reject unsupported variants.
- Check structure and size bounds before processing.
- Verify signatures and required commitments.
- Compare organization, vault, principal, grant, revisions, epochs, and key versions against independent authoritative context.
- 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.