eCryptfs Header

Byte address Content Usage


Unencrypted file size

Generic management


eCryptfs special marker



eCryptfs flags



eCryptfs extent size

Generic management


eCryptfs header extents count

Generic management


RFC2440 authentication token packet set






Encrypted data


The table above describes the layout of the information found in the eCryptfs header section, providing cryptographic material and generic information about the file.

The payload of the file is divided into "extents" (blocks of fixed size that can be individually encrypted or decrypted on demand).
The "extent size" indicates how large in byte extents are in this file.
The "header extents count" indicates how much extents containing header/padding information there are before the encrypted data.

Below is a hexadecimal dump of an eCryptfs file:

00000000  00 00 00 00 00 00 00 12  
          /* unencrypted file size */
                                   0d 8f e7 a8 31 0e 50 5d  
                                   /* eCryptfs special marker*/
00000010  03 00 00 02 
          /* flags */ -- file format version == 03
                      -- properties = IS_ENCRYPTED
                      00 00 10 00  
                      /* H.E.S.*/ -- Extent Size (big-endian)
                                   00 02 -- # of headers extents                                                        
RFC2440 authentication token packet set> 8c 1d 04 07 03 01

00000020  00 11 22 33 44 55 66 77  60 da 4c 8e f7 92 60 08  
00000030  61 c3 9d 59 09 73 d9 83  c4 
                                      ed 16 62 08 5f 43 4f  
00000040  4e 53 4f 4c 45 00 00 00  00 5a 4a 2d 2e 49 56 73                       
00000050  f1                          /** key signature */
             00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
00002000 <encrypted data starts here: 2 * 0x1000>

Is it an eCryptfs file ?

Read the special marker in the header extent. It contains two 32-bit, big-endian words w0 and w1 such that XOR(w0, w1) == 0x3c81b7f5. This is the signature of an eCryptfs file. You can then check the flags in bytes 16 (file format version, expected to be 3) and 19 (properties, bit 1 set indicates an encrypted file).

Where does the encrypted payload start ?

The payload starts after <header extents count> blocks of <extent size> bytes. Here, this is 2 times 4096 (0x1000) bytes. We also know that the file will be only 18 bytes (<unencrypted file size>) once decrypted. Because eCryptfs uses block cryptography, this can be smaller than the size of the encrypted data section.

How to get the session key ?

The cryptography material is contained in the variable-sized authentication token packet set chunk, starting at offset 26 in the header extent. Each packet in this set starts with a type byte followed by one or more size byte(s) and finally some payload bytes, as defined in section 4.3 of RFC2440.

The current firmware for Coaxlink only supports passphrases to authenticate users of the encrypted storage, meaning that the only two packets expected in the set are:

Symmetric key encrypted (packet tag 3), as defined in section 5.3 of the RFC
eCryptfs key signature (packet type 0x2d) following the generic “literal data” structure (packet tag 11) as described in section 5.9 of the RFC.

The key signature uniquely identifies the master key used to encrypt the session key contained in the tag-3 packet. eCryptfs uses it to look up for the corresponding key in its internal keyring.

According to §5.3 of the RFC:

If the encrypted session key is present, the result of applying the S2K [string to key] algorithm to the passphrase is used to decrypt just that encrypted session key field, using CFB mode with an IV [initialization vector] of all zeros.
The decryption result consists of a one-octet algorithm identifier that specifies the symmetric-key encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet, followed by the session key octets themselves.


On the sample encrypted file, we can tell from the “string to key” specifier that we will have to use “iterated and salted” algorithm (specifier #3, described at section of the RFC) using the SHA-512 hash algorithm (identifier #1), 65536 times.

This is as currently used in the Linux kernel implementation and it departs from the RFC2440 specifications.



The first 128-bit of the resulting hash gives us the “master key” required to decrypt the session key as indicated above.