eCryptfs: Architecture, Usage, and Encryption Process

eCryptfs is a Linux kernel‑integrated stacked filesystem that encrypts both file names and contents using per‑file symmetric keys protected by passphrase‑or public‑key‑encrypted key wrappers, managed by a user‑space daemon and kernel keyring, with Ubuntu installation via ecryptfs‑utils, mount commands, and a read/write flow that incurs performance overhead and cache‑based security risks.

OPPO Kernel Craftsman
OPPO Kernel Craftsman
OPPO Kernel Craftsman
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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Linux kerneleCryptfsencrypted filesystemfile encryptionstackable filesystem
OPPO Kernel Craftsman
Written by

OPPO Kernel Craftsman

Sharing Linux kernel-related cutting-edge technology, technical articles, technical news, and curated tutorials

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.