Security
The threat model, including the parts that are inconvenient
A tool that asks to hold the only copy of something owes you a precise account of what it protects, what it does not, and which of the two a given claim belongs to.
Client-side, always
Paths and content are both encrypted under a password-wrapped root key before anything leaves the machine. The provider stores opaque objects with opaque names.
Key-committing AEAD
Envelope key slots commit to their key, which closes the partitioning-oracle class of attacks against password-based decryption.
Calibrated Argon2id
RFC 9106 Argon2id with bounded, calibrated cost parameters and anti-downgrade AAD, so an attacker cannot negotiate you down to cheap parameters.
Two ways back in
Every vault is created with both a password slot and a BIP-39 recovery phrase. Rotating the password never disturbs the recovery phrase.
Tamper-evident audit log
A hash-chained log gives you integrity and ordering for every operation, with length attestable against an anchor.
Locked secret memory
Secrets live in mlock/VirtualLock-backed allocations that zeroize deterministically. All unsafe FFI is quarantined in one audited crate.
Primitives
Exactly what is running
No proprietary cryptography, no novel constructions. Standard primitives, composed conservatively, in a format that was frozen only after five rounds of adversarial review.
| Key derivation | Argon2id (RFC 9106), calibrated, bounded cost, anti-downgrade AAD |
|---|---|
| Content encryption | XChaCha20-Poly1305, key-committing, chunked for streaming |
| Key hierarchy | HKDF-SHA512 domain-separated subkeys from an immutable random root |
| Integrity | BLAKE3 per-chunk AAD plus a whole-object footer |
| Per-object keys | A fresh random DEK per object, wrapped into the envelope |
| Recipient sharing | X25519 + ML-KEM-768 hybrid (X-Wing-style combiner), kem_id=1 |
| Index at rest | SQLCipher with keyed hashing, per-row AEAD and page-level cipher |
| Secret memory | mlock / VirtualLock allocations with deterministic zeroization |
Limits
What DCTL does not protect you from
Stated here rather than buried in an appendix. If any of these matter to your threat model, they should change your decision — and you should find that out now, not after migrating a petabyte.
No forward secrecy against key compromise
The at-rest design uses static recipients by choice. Compromise of the root or a recipient key exposes data encrypted to it.
No sender authentication in v1
The format gives you confidentiality and integrity, not origin authentication. Do not use it to prove who wrote an object.
Some metadata is visible to the provider
Object sizes, object counts and the shape of the sharing graph are observable by whoever stores the ciphertext. Names and paths are not.
Hardware second factor is not shipped
A --key-file second factor is specified but not yet implemented, and is refused loudly rather than silently ignored.
Classical TLS in transit, for now
Transport currently uses classical rustls. Payloads are already symmetric-encrypted before transit; hybrid PQ-TLS is the tracked next step.
Disclosure
Reporting a vulnerability
If you have found a flaw in DCTL, we want to hear about it before anyone else does.
Email [email protected] with enough detail to reproduce the issue. We will acknowledge within three business days, keep you updated while we investigate, and credit you in the release notes unless you would rather we did not.
Please give us a reasonable window to ship a fix before publishing. We will not pursue legal action against good-faith research conducted under these terms.
Evaluate it against your own threat model.
The format specification, the threat model and the reference decoder are all published. Bring your security team — that is what the documents are for.