LibreCrypt: Open-Source disk encryption for Windows
NOTE: This CDB layout is *_obsolete_; all new volumes should use the latest CDB format.*
OBSOLETE This format is used by older versions of FreeOTFE, but not by LibreCrypt. LibreCrypt supports only (CDB Format ID 4)
A LibreCrypt container critical data block consists of "CDL" bits of data. The following table describes the high-level layout of a LibreCrypt CDB:
Critical data block:
|
Color key:
Color | Encryption used |
---|---|
Red items are not encrypted | |
Blue items are encrypted with the user's chosen cypher together with a "critical data key" derived from the user's password, salt, and the user's chosen hash algorithm |
Seem intimidating? Read on, and all will become clear... When broken down into its component parts, the CDB structure is reasonably straightforward to understand.
Note: Throughout this document, the following definitions apply:
Variable | Definition |
---|---|
CDL | |
sl |
Password salt | Encrypted block | Random padding #1 |
Item name | Size (in bits) | Description |
---|---|---|
Password salt | sl (User specified to a max 512) | This data is used together with the user's password to derive the "critical data key". This key is then used to encrypt/decrypt the "Encrypted block". |
Encrypted block | If cbs>8 then: ((CDL - sl) div cbs) * cbs If cbs<=8 then: (CDL - sl) This size is referred to as "leb" | This block contains the actual key which is used to encrypt/decrypt the encrypted partition image. See below for further breakdown. |
Random padding #1 | ((CDL- sl) - leb) | Random "padding" data. Required to pad out any remaining, unused, bits in the "critical data block" |
_Total size:_ | CDL |
Check MAC | Volume details block |
As described above, this entire block is encrypted using the user's password, salt, and chosen hash and cypher algorithms.
As this block is encrypted, its length (in bits) must be a multiple of the cypher's blocksize.
Item name | Size (in bits) | Description |
---|---|---|
Check MAC | ml _Up to a maximum of **MML **bits _ | This is the MAC of the plaintext version of the "Volume details block". If hk is zero or undefined, then this hash will be either truncated to *MML *bits, or right-padded with 0 bits up to a maximum of *MML *bits |
Volume details | leb* - *MML ** | This stores the details of how to encrypt/decrypt the encrypted partition. |
_Total size:_ | leb |
CDB format ID | Volume flags | Encrypted partition image length | Master key length | Master key | Requested drive letter | Volume IV length | Random padding #2 |
Finally, we reach the details that the critical data block was designed to protect. All of the items within this block have bit order: MSB first.
Item name | Size (in bits) | Description |
---|---|---|
CDB format ID | 8 | This is a version ID which identifies the layout of the remainder of the volume details block When this layout format is used, this will always be set to 2. |
Volume flags | 32 | Bitmap flagging various items.
Bit - Description 0 - Use different IVs for each sector 0 = Use NULL IV for all sectors 1 = Use sector ID (possibly hashed; see bit 3) as IV 1 - Sector ID zero is at the start of the file 0 = Sector ID zero is at the start of the encrypted data 1 = Sector ID zero is at the start of the host volume file 2 - (unused) 3 - Hash sector ID before use (only valid if bit 0 is set) 0 = Use sector ID as sector IV - do not hash before using 1 = Hash sector ID before using as sector IV |
Encrypted partition image length | 64 | This stores the length *of the encrypted partition image *in bytes. |
Master key length | 32 | This will be set to the length of the master key in bits. |
Master key | _cks _ | This is set to the random data generated when the volume was created; and is the en/decryption key used to encrypt the encrypted partition image |
Volume IV length | 32 | |
_Total size:_ | (leb** - MML) |
The design of the critical data layout eliminates the need for the cypher/hash used to be stored anywhere, denying an attacker this information and increasing the amount of work required to attack a volume file.
The "password salt" appears before the "encrypted block", and no indication of the length of salt used is stored anywhere in order to prevent an attacker from even knowing where the "encrypted block" starts within the CDB.
The "Check MAC" is limited to 512 bits. This is limited for practical reasons as some kind of limit is required if the critical data block is to be of a predetermined size. See section on mounting volume files for how multiple matching MACs are handled.
The "Password salt" is (fairly arbitrarily) limited to 512 bits. Again, this is primarily done for practical reasons.
Although at time of writing (March 2005) this limit to the length of salt used should be sufficient, the format of the critical data block (with included layout version ID) does allow future scope for modification in order to allow the critical data block to be extended (e.g. from 4096 to 8192 bits), should this limit be deemed inadequate..
The "Encrypted block" does contain a certain amount of data that may be reasonably guessed by an attacker (e.g. the CDB format ID), however this would be of very limited use to an attacker launching a "known plaintext" attack as the amount of this data is minimal, and as with pretty much any transparant encryption system the encrypted partition image can reasonably expected to contain significantly more known plaintext than the CDB anyway (e.g. the partition's boot sector)
The encrypted data block within a CDB is encrypted using:
The key used for this encryption/decryption depends on the CDB format used to create the CDB.
For older (CDB format 1) volumes, the key is derived as follows:
For newer (CDB format 2) volumes, the key is derived as follows:
The manner in which the check bytes within a CDB are calculated depends on the CDB format used.
For older (CDB format 1) volumes, the check bytes are calculated by simply hashing the volume details block with the user's choice of hash algorithm.
For newer (CDB format 2) volumes, the check bytes are calculated by passing the volume details block through HMAC with the user's choice of hash algorithm. In doing so, the derived key used to encrypt/decrypt the CDB is used as the HMAC key.