Skip to main content

// THE SECURITY MODEL

Built so we couldn't read your files if we tried.

Local-first encryption, post-quantum recovery keys, a public vault format spec, and signed Windows releases. Everything below is anchored to the source — no marketing shortcuts, no claims we can't back.

  • Local-first Files never leave your machine
  • AES-256-GCM NIST-published authenticated encryption
  • Post-quantum recovery ML-KEM-768 (FIPS 203)
  • Public format spec Versioned, stable, public

// ARCHITECTURE

Five layers. Five well-deployed primitives.

Every byte goes through these five layers. We didn't invent any of them — they're NIST publications and standards in widespread deployment. Below each layer: what it does, where it's specified, and the parameter values we use.

  1. 01
    Argon2id — Password → Key

    Derives a 32-byte symmetric key from the user's password. Slow on purpose — resists brute-force and GPU attacks.

    256 MB · 3 iter · 4 threads · 32-byte salt

    RFC 9106
  2. 02
    AES-256-GCM — Master key protection

    Encrypts the actual master key at rest. The hybrid construction layers a post-quantum KEM around the master key so the recovery path stays safe under future quantum attack.

    Hybrid PQ wrap — default for new vaults since v0.3

    NIST SP 800-38D
  3. 03
    HKDF-SHA256 — Per-file / per-directory keys

    Derives a unique key for every file and every directory. A compromise of one file's key never compromises another.

    From master key + per-entity salt

    RFC 5869
  4. 04
    AES-256-GCM — File content

    Authenticated encryption for every chunk. Tampering is detected on read. Directory metadata (filenames, sizes, timestamps) is encrypted the same way.

    Chunked (256 KB / 1 MB / 4 MB) · per-chunk random nonce

    NIST SP 800-38D
  5. 05
    ML-KEM-768 — Recovery

    Post-quantum key encapsulation. Lattice-based, not vulnerable to Shor's algorithm. The recovery private key is shown once at vault creation and kept offline.

    Hybrid: PQ wraps a key that decrypts the master key

    NIST FIPS 203

// HOW A VAULT WORKS

Walk through it.

The four operations that matter — create, add a file, lock, unlock — each traced from input through the crypto chain to disk.

Creating a vault

The user picks a password. Argon2id derives a 32-byte key with the parameters above. A new random 32-byte master key is generated and encrypted under the Argon2id-derived key — that ciphertext lives at vault_root/.<random>/keys/master.key.

ML-KEM-768 generates a recovery keypair. The public key is stored; the encrypted ML-KEM ciphertext that wraps the master key is stored; the user is shown the recovery private key once on a printable page.

vault.json is written next to the keys directory. It contains KDF params, a random root-directory ID, and an HMAC-SHA256 integrity tag (verified on every unlock — detects wrong passwords and tampered configs). No secrets are stored in plaintext.

On-disk layout
.<16-hex-chars>/
8 random bytes, hex-encoded
vault.json
plaintext — KDF params, root id, HMAC tag
keys/
master.key
AES-256-GCM(master_key, Argon2id_key)
recovery.pub
1184-byte ML-KEM-768 public key
recovery.key
ML-KEM-768 encapsulation of master_key
hybrid.priv
encrypted ephemeral PQ private key

Adding a file

The file's contents are split into fixed-size chunks (configurable per vault — sizes available are 256 KB, 1 MB, and 4 MB).

HKDF-SHA256 derives a per-file encryption key from the master key + the file's ID (used as HKDF salt). Every chunk of that file is encrypted under the same per-file key with AES-256-GCM and a fresh random 12-byte nonce per chunk. The chunk is written to f/<2-hex>/<62-hex>.<N> where the path is SHA-256(file_id) split into a 2-level hash directory and .N is the chunk index.

Directory metadata (file names, sizes, timestamps) is encrypted separately under per-directory keys (same HKDF chain).

Locking

Locking is the in-memory state change: the master key is zeroed in process memory. The on-disk vault is already at rest in its encrypted form — nothing to flush. Mounted drives (Dokany / FUSE / WebDAV) are unmounted.

Unlocking

The user types the password. Argon2id re-derives the Argon2id key from the password + stored salt. The master key is decrypted from keys/master.key. Per-file keys are derived on demand via HKDF as files are accessed.

There is no "unlock log" — repeated wrong passwords just fail to decrypt the master key, with the Argon2id cost as the DoS guard.

// MULTI-FACTOR UNLOCK

A password alone is one secret. Add a second.

Cypherrum supports a second factor at unlock time — something you have alongside something you know.

Windows Hello. The OS holds a biometric or device-bound credential in the TPM; unlock requires both the vault password and Hello consent. Shipping since v0.3.

FIDO2 / passkey. Any FIDO2-compatible hardware key (YubiKey, Solo, Nitrokey, etc.) gates the master-key derivation. The key never leaves the device. Shipping since v0.4.

Password-manager integration. The vault password can come from Bitwarden, 1Password, KeePassXC, pass, LastPass, or a custom webhook. Useful for shared / scripted environments. Shipping since v0.5.

Feature Windows macOS Linux
Windows Hello (biometric) v0.3 — —
FIDO2 / passkey (YubiKey, etc.) v0.4 v0.4 v0.4
Password-manager unlock v0.5 v0.5 v0.5

Mobile multi-factor isn't yet shipping — see limitations.

// POST-QUANTUM RECOVERY

Recovery, ready for the day after tomorrow.

Recovery secrets are long-lived. You write them down, store them, and they sit for years. That makes them a perfect target for the "harvest now, decrypt later" attack — recording today's ciphertext and breaking it once a cryptographically relevant quantum computer arrives.

Cypherrum's recovery path uses ML-KEM-768 (NIST FIPS 203, formerly Kyber). It's a lattice-based key encapsulation mechanism — not vulnerable to Shor's algorithm. The recovery private key is shown once at vault creation; you print it and keep it offline.

The construction is hybrid: ML-KEM wraps a key that decrypts the master key. If ML-KEM is ever broken classically, a classical layer underneath still holds. Shipping since v0.3.

  1. STEP 1

    Generate

    At vault creation, an ML-KEM-768 keypair is created. Public key stays in the vault; private key is destined for you.

  2. STEP 2

    Print + store offline

    The private key is shown ONCE as a printable recovery sheet. Paper safe, hardware safe, wherever — but offline.

  3. STEP 3

    Use to unlock

    When you've lost the password, feed the private key back to Cypherrum and it decrypts the master key directly, bypassing Argon2id.

// SHARING SAFELY

Cypherrum Mesh — without making sharing a security afterthought.

Cypherrum Mesh is LAN + relay sharing. A vault's master key can be passed to a contact's device — a pair-bonded peer you've explicitly trusted.

Key transfer. When you share a vault, the per-member key that unlocks the master key is wrapped under ML-KEM-768 (FIPS 203) — the same post-quantum primitive used for recovery. Two-step bootstrap: the joiner generates an ML-KEM keypair on first run, posts the public key (HMAC-bound to the invite password) to the inviter's relay inbox; the inviter ships back the ShareToken. QR-paired contacts skip the inbox step — their pubkey rides in the pairing code itself. Shipped in v0.12.0 (2026-05-17). Per-share mesh_share_delivered events land in the vault's audit log.

Access revocation. Rotating a vault's password re-encrypts the master key under the new password-derived key. Previously delivered shares of the old master-key wrap remain valid until rotation — so the recommended sequence is revoke → rotate.

Remote mounts. When a contact mounts a shared vault over WebDAV, Cypherrum issues a per-session ~96-bit password, loopback-only by default. Network exposure is opt-in.

Honest note: The v0.12.0 mesh key transfer is PQ-safe; the surrounding envelopes (backup and export blobs) are still classical. Wrapping those in ML-KEM-768 is tracked for v1.1. Pre-v0.12.0 vault members configured under the classical-v1 path keep working unchanged — they coexist forever via an optional schema field.

// TRANSPARENCY

What's not encrypted.

These minor leaks are documented in the vault format spec — not hidden. They're well-understood and acceptable for the threat model below.

  • vault.json

    Plaintext on disk. Contains only KDF parameters (memory, iterations, parallelism, salt) and a random root directory ID. No secrets.

  • Vault root directory name

    A random 8-byte hex string (.<16-hex>). Hides the vault from casual file browsing but isn't a security boundary.

  • File count

    Visible from the number of chunk files in f/<2-hex>/ directories. Reveals approximate file count and rough size distribution.

  • Filesystem timestamps

    mtime, atime, and ctime on the chunk files are whatever the filesystem records. Cypherrum doesn't normalize them.

// THREAT MODEL

Who we protect against — and who we don't.

Concrete adversaries, with the actual protection mechanism. The "Notes" column is what the user can do to extend protection further.

Adversary What Cypherrum does Notes
Lost or stolen device Vault is encrypted at rest. Argon2id forces ~1s per password attempt. Wrong passwords fail without revealing whether they were close. Use a strong password. Enable Windows Hello / FIDO2 for a second factor.
Malicious cloud-sync provider Provider sees only ciphertext + the small plaintext vault.json + chunk-file counts. No filenames, no contents, no per-file metadata. Sync through any provider (Dropbox, OneDrive, iCloud, Syncthing). Cypherrum never talks to them.
Harvest now, decrypt later Recovery path uses ML-KEM-768 (FIPS 203). Daily encryption is AES-256-GCM, already quantum-resistant for confidentiality with a 128-bit margin under Grover. Mesh key transfer uses ML-KEM-768 since v0.12.0 (FIPS 203 ShareToken v0x02 wrapping the per-member key). Backup and export envelopes are still classical — moving to PQ in v1.1.
Untrusted mesh relay Relay sees only encrypted invite blobs and signed messages. Cannot decrypt vault keys in transit. WebDAV uses per-session ~96-bit credentials, loopback-only by default. The relay is open source under GPL-3.0 — inspect or self-host.
Active malware on an unlocked machine None. Once the vault is mounted, files are accessible to anything that can read process memory or the mounted drive letter. Lock when not in use. Use auto-lock on idle (v0.2).
Nation-state with physical access while locked Same as 'lost device' but assume stronger compute. Argon2id parameters are tunable upward. Doesn't replace airgap for genuinely classified material.

// HONEST LIMITATIONS

What we don't claim yet.

Trust is built from acknowledged gaps, not unverified guarantees. Every item below is on our internal roadmap; we update this page when a gap closes.

  • No independent third-party audit yet

    A Cure53-level audit of core crypto, mesh protocol, and mobile is tracked for v1.0.0 in our public ROADMAP — currently unchecked. Until it lands, the primitives are NIST-published standards and the format is publicly documented for independent review.

  • macOS code signing isn't shipping notarized builds yet

    Windows binaries are Authenticode-signed by Logiqum Korlátolt Felelősségű Társaság via Azure Artifact Signing (formerly Trusted Signing) since v0.11.1 (2026-05-14). macOS notarization is parked as a v1.0 blocker — Apple Developer Program enrollment is required. Until it ships, Gatekeeper warns on first launch.

  • PQ-wrapped backup/export envelopes — planned, not shipped

    Daily encryption is already post-quantum-capable (ML-KEM recovery + classical AES with 128-bit margin under Grover). Mesh key transfer uses ML-KEM-768 since v0.12.0 (the per-member key rides in a v0x02 ShareToken; invite-link contacts get it via a relay-inbox bootstrap, QR-paired contacts get it inline). What's not yet PQ is the backup/export envelope layer — those archives are still classically wrapped. Tracked for v1.1.

  • Mobile apps — not yet shipped

    Android + iOS are v1.0 targets. Today Cypherrum is desktop-only (Windows / macOS / Linux).

  • Source availability of the main app

    The cypherrum-relay component is open source under GPL-3.0. The desktop app is closed source — license holders receive signed binaries, not source code. We do not position the desktop app as 'open source.' The on-disk vault format is documented publicly so anyone can write a compatible reader without our source.

// CODE SIGNING & VERIFICATION

Verify what you downloaded.

Cypherrum Windows binaries — CypherrumSetup-x.y.z.exe, cypherrum.exe, cypherrum-service.exe, and cypherrum-e2e.exe — ship Authenticode-signed by Logiqum Korlátolt Felelősségű Társaság via Azure Artifact Signing (formerly Trusted Signing) since v0.11.1 (2026-05-14). The verified publisher field will show the full Hungarian legal name ("Logiqum Korlátolt Felelősségű Társaság") in Windows UAC prompts and in Explorer → Properties → Digital Signatures.

For Linux, macOS, or paranoid cross-platform verification, every GitHub release publishes a SHA256SUMS manifest plus a detached ed25519 signature (SHA256SUMS.sig). Verify the signature first, then your download. 

# Windows verification (PowerShell)
Get-AuthenticodeSignature CypherrumSetup-*.exe | Format-List
# Expected: Status=Valid
# SignerCertificate publisher="Logiqum Korlátolt Felelősségű Társaság"
# Linux / macOS / cross-platform — signed SHA-256 manifest
# 1. Import the Cypherrum release-signing key (one-time)
gpg --import RELEASE-SIGNING-KEY.asc
# 2. Verify the manifest signature
gpg --verify SHA256SUMS.sig SHA256SUMS
# 3. Verify your binary matches the manifest
sha256sum -c SHA256SUMS --ignore-missing

// THE FORMAT IS PUBLIC

The format is public. Audit it yourself.

The complete on-disk format is documented — every byte, every algorithm, every parameter — versioned and stable.

You can write your own implementation. We won't break the format on you without a version bump.

Read the vault format spec → Download