How Encrypted-Home + eCryptfs Works
March 1, 2009
One comment to my last post, Jaunty Encrypted Home Directories, deserves a blog post of its own to answer..
Very cool. So does this mean there’s now a separation of a user’s password from the user’s decryption password? This was an issue brought up in your previous post–oftentimes we want our encrypted data passphrase to be significantly longer than our user passphrase.
Yes. And we provided that same separation in Intrepid as well. Let me explain in better detail how this feature works…
When you login, the pam_ecryptfs module takes your login passphrase (which is usually pretty short, and easy to remember), and symmetrically decrypts the file ~/.ecryptfs/wrapped-passphrase, which will yield your mount passphrase.
Your mount passphrase is a randomly generated 128-bit key. This is very hard to remember, and rather hard to guess. 2^128 is a big number!
This mount passphrase is salted, hashed 65536 times using sha512 (i.e. key strengthened), and loaded into your kernel keyring. In eCryptfs terms, the salted, hashed passphrase is your “file encryption key, encryption key“, or fekek.
New for Jaunty (and the upstream 2.6.29 kernel), we have encrypted filenames too. In this case, the mount passphrase is salted with a different value, hashed 65536 times using sha512, and also loaded into your kernel keyring. This second key is your “filename encryption key“, or fnek.
Now, every time the kernel encounters an encrypted filename in your encrypted home directory, it is decrypted using your fnek and presented to you in plaintext.
To read/write encrypted data from/to a file, your fekek is used to decrypt the “file encryption key“, or fek, which is embedded in the header of the file. This embedded fek is unique per file! This means that two files, with the exact same contents, will produce two completely different encrypted files, which helps thwart known-plaintext attacks.
Does that explanation help?