Inferno's CRYPTFILE(4 )

NAME

cryptfile - encrypted block file

SYNOPSIS

mount { cryptfile [ -Ddi ] [ -k keyspec ] [ -m mode ] [ -l keybits ] file } mtpt

DESCRIPTION

Cryptfile provides unencrypted acces to the encrypted file. File contains the encrypted data which cryptfile serves as a file called ``data'' over styx. It allows random access on sector boundaries (512 bytes currently). Two modes of operation are supported: XTS (recommended) and CBC with sector-encrypted IV's. The encryption algorithm is AES with key lengths of 128, 192 or 256 bits. The first two sectors of file contain a header with all information except the password to start serving the decrypted file.

Options

-D: Print styx trace messages.
-d: Print debugging messages.
-i: Initialize file with new parameters (a new salt for the password, and new key for the data). Parameters can be set with -land -m.
-k keyspec: Add keyspec to the request to factotum for the password.
-l keybits: The length of the key to use for the AES encryption, in bits. The default is 128. Valid values: 128, 192, 256.
-m mode: The mode of encryption. Possible values: "aes-cbc", "aes-xts". The default is "aes-xts".

Security: The first two sectors of file contains a header, all later sectors contain the encrypted data. At startup (and on the ``data'' read/write after a ``forget'' ctl message), the following steps are executed:
- Request a password from factotum.
- Use ``Password Based Key Derivation Function 2.0'' (PKCS#5) to derive a key from the password. The salt, number of rounds and number of bits are taken from the header.
- The initialization vector from the header and the derived key are used to decrypt the actual key used for encrypting/decrypting. The data decrypted is actually: random cookie || key || (sha1 of random cookie || key || header).
Use of the key derivation function makes password guessing inefficient (the salt prevents use of pre-calculated dictionaries). Using a key stored in the header, instead of directly using the derived key, makes it possible to change the password without having to re-encrypt all data. The (encrypted) SHA1-hash along with the (encrypted) key allows verification of the user-entered password, preventing misinterpretation and possible destruction (by overwriting by e.g. file system repair tools) of data. XTS (XEX-TCB-CTS (sic)) is the recommended mode. It is a ``tweaked'' mode and ensures that each sector has a different ciphertext, even when storing the same data. The CTS part is for sector sizes that are not a multiple of the encryption algorithm block size. Since this is very uncommon, it is not implemented. The CBC-mode encrypts each sector in CBC-mode with the encrypted sector number as IV. This too ensures that a plaintext has a different ciphertext on each sector it is stored.

Styx

Accessing the file ``data'' at non-sector-boundary offsets, or with a length not a multiple of the sector size, the operation fails. Otherwise it is just like any other file. A null wstat causes a flush of the underlying file. Additionally, a file ``ctl'' is served. The following commands are understood:

forget: Remove the keys from memory. Subsequent access to the file causes a new request to factotum for the password.
debug or nodebug: Enable/disable styx trace printing, and debug message printing.

EXAMPLE

The initialize an encrypted file and start a fresh kfs on it:

	mount {cryptfile -i -m aes-xts -l 128 $home/encrypted} /n/decrypted/
	mount {disk/kfs -r /n/decrypted/data} /n/kfs

And to mount a previously initialized encrypted file:

	mount {cryptfile $home/encrypted} /n/decrypted/

SOURCE

/appl/cmd/cryptfile.b
/appl/lib/aesxts.b
/appl/lib/pbkdf2.b

BUGS

It might not be the best idea to make the header with the real encryption key verifiable.