PhantomVault is in development and is not available yet. We're building it for Apple silicon Macs running macOS 27 or later. Here's how the current cryptographic design fits together, plus a clear look at the features that still need to be built and tested.
Why use a separate Vault when your Mac already has FileVault?
FileVault protects a Mac's startup disk while the computer is powered off. Once you sign in, macOS and your apps can access files according to your account permissions. An application-level Vault adds a separate unlock boundary for selected files. The two protections serve different purposes, and PhantomVault is not a replacement for FileVault.
How the pieces fit together
Each Vault begins with a random 256-bit master key. Keys derived from that master key protect the Vault's contents using AES-256-GCM. GCM is an authenticated encryption mode, which means it both encrypts data and detects tampering.
AES-256 is considered resistant to known quantum attacks. That does not promise immunity from every future attack, and it does not turn AES into post-quantum public-key cryptography. PhantomVault uses different tools for content encryption and optional post-quantum key protection.
Your passphrase and Argon2id
The Vault passphrase is processed with Argon2id, a memory-hard password derivation function. This makes each password guess deliberately expensive. A strong, unique passphrase is still important, and the passphrase is required in both standard and Dual-Key modes.
What Dual-Key Protection means in practice
Optional Dual-Key Protection uses ML-KEM-1024, the highest-strength parameter set of the NIST-standardized post-quantum key-encapsulation mechanism in FIPS 203. ML-KEM-1024 establishes a shared secret. PhantomVault then uses HKDF to derive a wrapping key from that secret, and AES-256-GCM wraps the Vault's master key.
This is why "dual-key protection" is more accurate than "dual encryption." ML-KEM-1024 does not encrypt every file a second time. It adds a separate requirement for recovering the master key that unlocks the Vault.
Where the second key lives
The plan gives you two places to keep the required ML-KEM-1024 private key:
- Device-bound: Private-key operations use the Secure Enclave. A device-bound representation is stored in the local Keychain, tying access to that Mac.
- Account-bound: The ML-KEM-1024 private-key seed is stored in the user's synchronizable iCloud Keychain, allowing access from supported Macs signed in to the same Apple account.
The account-bound option does not place the Vault's files or AES master key in iCloud Keychain. In both custody modes, the Vault passphrase remains required.
What still needs to be built and tested
The launch plan includes optional file disguises and decoy Vaults that can present alternate content in a coercion scenario. Those capabilities are still under development. Current development builds do not enable decoy Vault creation, so we're not presenting it as available or verified.
Plausible deniability is not established by adding a second password alone. It depends on the complete system. Validation must look for practical differences in file structure, timing, Keychain artifacts, logs, backups, mounting behavior, and error paths. PhantomSecure will publish the final behavior and limitations after that work is complete.