What steps does CGD use to encrypt information, and which does it use for the inverse path?

RD: First, cgdconfig will read the parameters file to obtain configuration parameters such as the key generation method, the encryption algorithm, the key length, and the Initialization Vector generation method.

The default key generation method is PKCS#5 PBKDF2, which uses a pass phrase. PCKS#5 PBKDF2 is a salted iterated hash. The salt prevents offline dictionary attacks, so you cannot precompute a dictionary without having access to the parameters file. Iterating makes each guess in a dictionary attack more expensive. The iteration count is defaulted to make the algorithm take 2 seconds on the current hardware.

The currently supported encryption algorithms are AES (128-, 192-, and 256-bit keys), blowfish (40-448-bit key), and 3DES (192-bit key). Providing multiple ciphers allows the user to make trade-offs between security and performance. In the case that weaknesses in a cipher are discovered, the user can switch to another cipher without needing to upgrade to a new version of the operating system.

Each sector is encrypted independently. To encrypt a sector:

An Initialization Vector is generated via the configured IV method.

The sector is encrypted using the configured encryption algorithm with the IV generated from step 1.

Decryption operates in the same way.

Once I have an encrypted slice, can I switch cipher or disable cgd?

RD: There is currently no way to change the encryption type of an existing partition in place. The procedure to accomplish this is to create a new partition and move the data to it. I have been considering writing a tool to do this, though.

Does it interact in a special way with hardware/software RAID?

RD: No.

Does it take advantage of cryptography hardware such as accelerators and random number generators?

RD: Not yet, but I've been planning to do this at some point.

Is there a RAM/CPU minimum requirement?

RD: There is no minimum RAM or CPU requirement, but one will find that slower CPUs will impose a larger performance penalty.

How much does it limit I/O performance?

RD: It depends on the speed of the CPU versus the speed of the disks. There are two main effects. The maximum throughput can be limited by the CPU speed. Also, CGD will impose an additional latency on each disk operation, since the encryption must occur before writes and the decryption must occur after reads.

For laptops with Speed Step, CGD's performance will differ greatly in the different modes.

I think that every laptop owner is terrified by the idea of having it stolen. If such a bad event happens, what type of protection does CGD offer against an attacker with physical access to the disk?

RD: If the laptop is off, then the attacker would have to break the cryptography either by performing a dictionary attack on your pass phrase or by trying to brute-force the key.

A dictionary attack is attempting to guess the pass phrase which is used to generate the key that encrypts the disk. It is generally the most feasible attack on any cryptographic system, since users do not choose pass phrases which are nearly as secure as modern ciphers. CGD uses PKCS#5 PBKDF2 (an iterated salted hash) to frustrate dictionary attacks. What this does is increase the computation required to guess each pass phrase. CGD also provides a mechanism for 2-factor authentication where additional key material can be stored on a USB device.

A brute-force attack on the key is guessing the key to the cipher. This should be infeasible for all of the ciphers that CGD supports: AES 128, AES 192, AES 256, 3DES, and Blowfish. All of these have keys that are over 100 bits long and would take an average of over 2^100 guesses.

If the laptop is stolen while it is still on or in suspend mode, then an attacker might be able to retrieve the key from memory.