Security Architecture: Keys, Files and Honest Limits
Hidden Folder encrypts each file with AES-256-GCM using a random key. Those keys are wrapped by a master key, which is wrapped by a key derived from your pattern with PBKDF2-HMAC-SHA512 at 600,000 rounds. Decrypted content stays in memory and never touches the disk. The code is open source so people can check.
What is the design?
Standard parts, assembled carefully. The crypto comes from Apple's CryptoKit and CommonCrypto. The app does not implement any cryptographic primitive itself.
The key hierarchy
- Pattern
- Vault key (PBKDF2-SHA512, 600K)
- Master key (random 256-bit)
- File key per item
- AES-256-GCM
| Key | Where it comes from | What it protects |
|---|---|---|
| Device salt | 32 random bytes, stored in the Keychain on this Mac only | Binds the vault key to this Mac |
| Vault key | PBKDF2-HMAC-SHA512 of the pattern, 600,000 rounds | The encrypted index and the wrapped master key |
| Master key | Random 256-bit key per vault | File content, thumbnails and metadata |
| Recovery key | PBKDF2-HMAC-SHA512 of the recovery phrase, 800,000 rounds | The recovery envelope that holds the vault key |
| Backup key | Separate pattern-derived key with a distinct label | The iCloud backup records |
How files are stored
- Large files are cut into 1 MiB chunks. Each chunk has its own random 96-bit nonce.
- Authenticated data includes the file id, chunk index and a final-chunk flag. Reordering or truncating chunks is detected.
- File names on disk are random. Original names, dates and tags live only in the encrypted index.
- Thumbnails are encrypted the same way.
- The vault folder is excluded from Spotlight and marked so it is not indexed.
{
"cipher": "AES-256-GCM",
"kdf": "PBKDF2-HMAC-SHA512",
"iterations": 600000,
"salt": "device_keychain_salt",
"analytics": "off by default",
"source": "open (GPL-3.0)"
}Runtime rules
- No plaintext user content is written to disk. Images decode from memory, and video plays through a loader that decrypts chunks on demand.
- Export is the only way out, and only when you ask.
- On lock, keys are wiped from memory where practical and decoded media is released.
- Logs never contain patterns, phrases, keys or file names.
- The App Sandbox is on.
- Analytics are off by default and opt-in. Crash reports are opt-in.
What it protects against
- Someone with your Mac account while the vault is locked.
- A copied vault folder.
- Apple or anyone else reading your iCloud backup.
- Casual snooping and accidental screen sharing.
What it does not protect against
- Malware or a keylogger on an unlocked Mac.
- Someone watching you draw the pattern.
- Forensics on flash storage after deletion.
- Someone timing the duress feature with instruments.
Metadata that stays visible: ciphertext sizes, counts (blurred by cover files), timestamps, the duress setting's Keychain item and, for shares, the iCloud account id.
Frequently asked questions
Has the app been audited?
Not yet. A community review and a paid audit are planned before launch. Until then treat the security claims as a design, not as a verified result.
Why is it open source?
So anyone can read what it does with your keys and files. Open source cannot prove it is bug-free, but it removes the need to trust marketing text.
Which licence?
GPL-3.0. Forks must stay open.
What network calls does the app make?
The beta makes none. Later versions need the network for iCloud backup, license checks and update checks. The README is meant to list them all.
Do you collect analytics?
No. Anonymous usage and error sharing exist only as an opt-in setting.
Who can I report a vulnerability to?
A security contact will be published with the repository. Until then use the contact on the About page.
References
Try security architecture on your Mac
Coming soon. Join the waitlist and we email the link.
Get early access