dirLocker is built with a "security-first" philosophy. This document details the cryptographic primitives and security mechanisms used.

All core cryptographic operations are handled by the vault-core Rust library to ensure memory safety and constant-time execution where possible.

Each vault is a single file (.vault or .vc) with the following encrypted structure:

1. Header: Unencrypted versioning and salt.
2. Key Slot Area: Encrypted master keys protected by user password (Argon2id).
3. Metadata Block: Encrypted file table (paths, attributes).
4. Content Store: Encrypted file chunks.

• Never stored on disk in plaintext.
• Encrypted by the user's password derived key.
• Held in protected memory (zeroed on drop in Rust).

• Generated cryptographically secure random bytes.
• Can decrypt the Master Key independently of the password.
• Must be stored offline by the user.

• Storage: Credentials are stored in the OS-provided Secure Store (Windows Credential Manager, macOS Keychain).
• Binding: Credentials are cryptographically bound to the Vault's UUID, not its file path.
• Access Control: Rely on OS-level enforcement (User Presence/Hello) before releasing the key.
  • Limitation: Some OS configs may allow "silent" unlock if the session is recently active (see known_limitations.md).

On supported platforms, dirLocker attempts to make the vault file "invisible" to casual inspection:

• Windows: Sets FileAttributes::Hidden and System attributes.
• macOS/Linux: Prefixes filename with . (dotfile).

Note: For a deep dive into the implementation of hidden volumes and plausible deniability, see Plausible Deniability.

dirLocker protects against:

• Passive analysis of the vault file.
• Offline brute-force attacks (mitigated by Argon2id).
• Data tampering (mitigated by GCM/Poly1305 integrity checks).

• Entropy: Random generation uses window.crypto.getRandomValues (CSPRNG), never Math.random.
• Memory Hygiene:
  • Clipboard is cleared 30 seconds after copying generated passwords.
  • Passwords in React state are minimized but cannot be guaranteed zeroed due to JS garbage collection.

dirLocker does NOT protect against:

• Compromised host OS (keyloggers, memory dumpers) while the vault is OPEN.
• Physical coercion (user forced to reveal password).