Security architecture.

A layered key architecture

Your password is not used as a simple, direct encryption key for every file. BLKH01E separates authentication, key derivation and data encryption across distinct layers, so that breaking one stage does not hand over the rest.

• A password is stretched with Argon2id, a memory-hard key-derivation function that raises the cost of brute-force attempts.
• Derived material protects a master key, which is further protected by device-bound key storage.
• Each item is sealed with its own per-item encryption key, so a single compromised key does not expose everything.
• Data is encrypted at rest with authenticated encryption that protects both confidentiality and integrity.

Modern cryptographic primitives

BLKH01E is built on well-established, modern primitives:

• Argon2id, password-based key derivation. Memory-hard derivation designed to increase the cost of brute-force attacks.
• ChaCha20-Poly1305, authenticated encryption. Protects data confidentiality and integrity together.
• X25519, key agreement. Modern elliptic-curve key agreement for establishing shared secrets.
• HKDF, key derivation & separation. Derives distinct keys from shared secret material.
• HMAC-SHA256, message authentication. Verifies message integrity and authenticity.
• SHA-256, cryptographic hashing. One-way hashing for integrity and fingerprints.

Note: the key exchange uses X25519 and is not post-quantum today. The vault at rest is symmetric (Argon2id, ChaCha20-Poly1305, 256-bit keys) and does not rely on that exchange. The roadmap includes a hybrid post-quantum key exchange (X25519 + ML-KEM) for the messaging layer, the same pattern adopted by Signal and Apple. BLKH01E does not claim quantum resistance until that ships.

Key space

256-bit keys yield roughly 1.15 × 10⁷⁷ possible combinations. When strong keys are properly generated and protected, exhaustive brute-force search is not considered practically feasible with current technology. This is a statement about scale, not a promise that any system is unbreakable.

Data locality

BLKH01E is designed around a local-first model. The core architecture does not rely on a central server that stores the contents of your private vault. There is no central private database to breach and no master password held on our servers. A capable adversary cannot request private vault contents from a server that does not possess them.

On-device AI and search

Search indexing (including OCR and audio transcription), semantic search and AI summaries run on the device, using Apple's on-device models where available. Content and prompts are not sent to external AI services. The model operates only on content you have already unlocked, results are displayed and discarded, and nothing new is written to disk. Password breach checking is opt-in and uses k-anonymity, so only a 5-character hash prefix is ever sent.

Threat model

Designed to protect against

• Unauthorized access to encrypted stored data
• Stolen encrypted storage
• Password brute-force attempts
• Centralized private data breaches
• Interception of encrypted message content

Outside the model / limitations

No cryptographic system can protect data that is exposed on a compromised device while it is actively being used. The following are outside the cryptographic threat model:

• Compromised devices
• Malware
• Data exposed while actively in use
• Screenshots
• Operating system vulnerabilities
• Third-party services
• Network metadata

Responsible disclosure

If you believe you have found a security issue, we want to hear from you. Please report it privately to security@blkh01e.com and allow reasonable time for a fix before any public disclosure. Please do not access, modify or delete data that is not yours while researching.

BLKH01E makes no claim of independent third-party audit or certification. Any such claims will only appear here once they genuinely exist.