Three independent layers — key derivation, content encryption, and filename encryption — built on AES-256-GCM, scrypt, and HKDF. Every layer is independently audited open-source cryptography.
scrypt is memory-hard — it requires a large, tunable amount of RAM to compute, not just CPU time. GPU clusters that can test billions of PBKDF2 hashes per second are constrained to thousands per second against scrypt. The work parameters are stored in gocryptfs.conf so they can be tuned upward over time.
The master key is never stored in plaintext. It lives in gocryptfs.conf as AES-256-GCM ciphertext, protected by the Key Encryption Key derived from your password. Changing your password only re-encrypts the config file — not a single data block in your vault needs to change.
Since gocryptfs v1.3, HKDF-SHA256 derives two independent keys from the master key: a Content Key for file data and a Filename Key for directory entries. Using the same raw key for both operations would create theoretical cross-context vulnerabilities; HKDF eliminates that risk with a provably independent derivation.
Think of scrypt as a bank vault combination that takes a full minute to check — even if you know the mechanism, trying millions of guesses takes years. Your password never directly touches your files.
Each 4 KiB block is independently encrypted and authenticated. The 128-bit GHASH authentication tag covers the entire block — a modified block cannot be silently substituted. Any bit flip or byte replacement causes an authentication tag mismatch, and the read operation fails immediately before any data is returned to the application.
Every write generates a new 128-bit random IV for the affected blocks. Reusing an IV under the same key with GCM is catastrophic — it reveals the authentication key and breaks confidentiality for both messages. By generating a fresh IV for every modification, the IV uniqueness property is guaranteed even when identical plaintext is written repeatedly.
The File ID and block number are included as AES-GCM Additional Authenticated Data (AAD). The authentication tag cryptographically covers this AAD. Transplanting a block — placing it at a different position within the same file, or moving it to a different file entirely — causes an authentication tag mismatch and is detected before any data is read.
Each 4 KiB block is a tamper-evident envelope sealed with a unique wax stamp every time it's resealed. Swapping envelopes between documents breaks the stamp — detected before any data is read.
CBC-mode filename encryption leaks common prefixes: two files both named invoice_2024_01.pdf and invoice_2024_02.pdf produce ciphertexts with a common prefix that reveals structural relationships. EME (ECB-Mix-ECB) treats the entire filename as a single wide block — no prefix of the plaintext is detectable in the ciphertext.
Each directory contains a gocryptfs.diriv file with a unique 128-bit IV. The same filename stored in two different directories produces completely different ciphertext because the encryption uses different IVs. An observer with access to the encrypted filesystem cannot match names across directory boundaries or infer directory structure from filename patterns.
After Base64 encoding, encrypted filenames are limited to 175 characters to stay within filesystem limits. Filenames that exceed this limit are stored by SHA-256 hash: the ciphertext goes into a companion gocryptfs.longname.[hash] file, and the encrypted directory entry contains just the hash. The directory listing reveals neither the original length nor any structural information.
EME scrambles the whole word at once instead of letter by letter. Two files both starting with invoice_ look completely unrelated in the encrypted directory.
Technical content sourced from the gocryptfs forward-mode cryptography documentation. MyCryptFS is built on gocryptfs; behavior may differ between gocryptfs versions. This page describes the current forward-mode design as of gocryptfs v2.
MyCryptFS encrypts folders on macOS
Open MyCryptFS →