eCryptfs: Architecture, Usage, and Encryption Process

eCryptfs is a powerful enterprise‑grade encrypted stacked filesystem introduced into the Linux kernel (version 2.6.19) by IBM researchers such as Halcrow and Thompson. It supports encryption of both file names and file contents.

1. Architecture Design

eCryptfs is stacked on top of an underlying filesystem. A user‑space daemon together with the kernel keyring manage encryption keys. When a user writes to an encrypted file, the VFS forwards the request to eCryptfs, which encrypts the data via the kernel Crypto API (AES, DES, etc.) before passing it to the lower filesystem. Reads follow the reverse path.

The design is influenced by the OpenPGP specification and follows two main principles:

1) Encryption of file names and contents using a symmetric File Encryption Key (FEK) that is randomly generated for each file.

2) Protection of the FEK: the FEK is encrypted (EFEK) with a user‑provided passphrase, a public‑key algorithm (e.g., RSA), or a TPM public key. The key that encrypts the FEK is called the File Encryption Key Encryption Key (FEFEK).

2. Usage on Ubuntu

Installation of the user‑space utilities:

sudo apt-get install ecryptfs-utils

Mounting an encrypted directory:

sudo mount -t ecryptfs /path/to/source /path/to/target

During the mount, the user provides a passphrase, selects an encryption algorithm, and the directory (e.g., my_cryptfs ) becomes encrypted. Files created under this directory are automatically encrypted, and after unmounting they appear as encrypted data.

3. Encryption/Decryption Flow

The data flow is illustrated in the diagram (image omitted). eCryptfs encrypts data in block units (extents) using symmetric algorithms such as AES‑128. Metadata (including file size, flags, and EFEK) is stored in the file header (minimum 8192 bytes). For reads, the encrypted FEK (EFEK) is first decrypted to obtain the FEK, which is then used to decrypt the data blocks via the Kernel Crypto API. Writes perform the inverse operation.

Key code paths include:

eCryptfs_open : parses metadata, decrypts EFEK to retrieve the FEK, and initializes the ecryptfs_crypt_stat structure for subsequent I/O.

eCryptfs_read : reads encrypted extents, decrypts them page‑by‑page using ecryptfs_decrypt_page() and crypt_extent() .

4. Drawbacks

Performance: Stacked filesystems incur overhead, and the additional encryption/decryption further degrades write performance, while reads benefit from cached plaintext.

Security risks: The plaintext data resides in the kernel page cache. If user‑space permissions are misconfigured or compromised, the cached data can be exposed.

5. Conclusion

The article provides an overview of eCryptfs’s architecture, usage steps, and internal encryption mechanisms. While performance and security considerations remain, improvements in hardware and kernel support continue to enhance its practicality.