![]() |
FreeOTFE |
![]() |
This section applies to the PC version of FreeOTFE only |
IMPORTANT: This is obvious, but... If you are using FTP to transfer your Linux volumes between your Linux and MS Windows systems, make sure you transfer the volume file in binary mode!
NOTE: At time of writing (17th July 2005), although FreeOTFE can read and write LUKS volumes, it cannot create them itself.
dd if=/dev/zero of=./vol_none bs=1M count=x
Where "x" is the size of the volume in MB.
At this point a new drive should appear, although at this stage it is unformatted and you will be given an error if you attempt to access it (e.g. using Windows Explorer)losetup /dev/loop0 <volume file> <various options>
mkdir ./mountpoint
mount /dev/loop0 ./mountpoint
Your volume file is now fully ready for use, although for security reasons it is highly recommended that you now initialize the volume by writing data to all its sectors before making any further use of it.mkdosfs /dev/loop0
This process is recommended because if omitted it may be possible
for an attacker to determine the amount of data you have stored on your
volume file (as stated above, the actual process of creating the volume
file consists of creating a suitably large file, filled with zeros)
Note:
It is important that this step be carried out if you intend using the
volume file just created as a "host" file for storing a second, hidden,
encrypted volume.
Note that if you do not:
(This does not appear to be documented; the above logic was derived from examining "util-linux-2.12p.diff" - one of the files included with loop-AES)
Cypher Selection
If the cypher selected ("-e" parameter passed as losetup) can support
different keysizes (e.g. AES supports 128/192/256 bit keysizes), and
the user doesn't specify the keysize to be used (i.e. you specify "-e
AES" as opposed to "-e AES128"), then the cypher will default to using
128 bit keys.
(From: http://loop-aes.sourceforge.net/loop-AES.README)
losetup /dev/loop1 /dev/mapper/myMapper mkdosfs /dev/loop1 ...
as opposed to just straight:
mkdosfs /dev/mapper/myMapper ...
This is carried out as (in my tests) the latter appears to result in failure:
# mkdosfs /dev/mapper/myMapper mkdosfs 2.8 (28 Feb 2001) mkdosfs: unable to get drive geometry for '/dev/mapper/myMapper'
FreeOTFE supports this form of key processing, which can be invoked by selecting the option "Hash with "A"s, if hash output is too short" on the Linux mount dialog.
Note that, under linux, the actual encryption/decryption key can be shown in its hex representation by running "dmsetup table".
For example, if the volume's password is "password1234567890ABC", then:
If AES (256 bit key) is used for encryption/decryption, and the user's
password is processed with RIPEMD-160, the actual encryption/decryption
key will be:
FAFE56C3BAB4CD216BA02474AC157EA555FA5711This is made up as follows:
D539285C28A6D8122D9464EE
FAFE56C3BAB4CD216BA02474AC157EA555FA5711 |
The first 160 bits are the RIPEMD-160 hash of "password1234567890ABC" |
D539285C28A6D8122D9464EE0AA3C4811DE0D846
|
The remaining bits are the first 96 bits taken from the RIPEMD-160 hash of "Apassword1234567890ABC" |
4EAB90A0D00CE0086EB59DA838CC888DThis is made up as follows:
D1270498F52EFFA562872664BB514F8E
2FA054980C9D92542F5801FDF82ADFEA
121E587A4EEBDF3B
4EAB90A0D00CE0086EB59DA838CC888D |
The first 128 bits are the MD5 hash of "password1234567890ABC" |
D1270498F52EFFA562872664BB514F8E |
The next 128 bits are the MD5 hash of "Apassword1234567890ABC" |
2FA054980C9D92542F5801FDF82ADFEA |
The next 128 bits are the MD5 hash of "AApassword1234567890ABC" |
121E587A4EEBDF3BD6CD437A1B2C32A
|
The remaining bits are the first 64 bits taken from the MD5 hash of "AAApassword1234567890ABC" |
The manner in which Linux uses ESSIV differs from FreeOTFE volumes in how the ESSIV encryption key is generated. Both hash the master encryption/decryption key to generate the key used for ESSIV, however dm-crypt uses the full hash output as the ESSIV key. This means that if you have a dm-crypt volume which is encrypted using 256 bit AES, and specify MD5 as the ESSIV hash, the ESSIV process will actually use AES-128 for creating the "salt" for ESSIV IVs (MD5 generates 128 bit hashes).
It is for this reason, you cannot create a dm-crypt volume under Linux
using 256 bit Twofish, and specify SHA-512 as the ESSIV hash; Twofish
doesn't support 512 bit keys, and so dm-crypt fails.
FreeOTFE supports LUKS to v1.1 of the LUKS specification. This is the latest version at time of writing (2nd December 2007)
![]() |
As well as using the "File | Linux | Mount file/partition..." menu items, LUKS volumes may also be mounted using the main "File | Mount file/partition..." menu items and toolbar buttons. (FreeOTFE detects LUKS volumes by their signature and offers to mount them appropriately) |
Also at time of writing (25th February 2007), the current LUKS implementation of "cryptsetup" only supports the SHA1 hash algorithm, although other hashes may be used for ESSIV.
Because of the way in which dm-crypt operates (see also the "dm-crypt" section on ESSIV, above), LUKS ESSIV doesn't do what you'd probably expect it to do. Specifically, if you have (for example) a Blowfish-448 encrypted volume, and specify cbc-essiv:sha256 for use as IVs - LUKS (dm-crypt) will actually use Blowfish-256 as the ESSIV cypher, and not Blowfish-448. In other words, the ESSIV cypher used will be from the same "family" of cypher (AES, Blowfish, Serpent, etc) - but will use the keylength which matches the ESSIV hash output length.
As a result of this, another option appears on the LUKS password entry dialog; "Base IV cypher on hash length". If this is checked, then when mounting an ESSIV volume, the keylength of the cypher used for ESSIV generation will be that of the ESSIV hash. If this is unchecked, the ESSIV cypher used will have the same keylength as the main bulk encryption cypher used for securing the encrypted disk image.
Most users will want this option checked.
FreeOTFE Supported LUKS Cyphers
The following table lists compatibility with LUKS cyphers:
Cypher |
Compatibility |
---|---|
aes | Supported by FreeOTFE. |
twofish | Supported by FreeOTFE. |
serpent | Supported by FreeOTFE. |
cast5 | Supported by FreeOTFE. |
cast6 | Supported by FreeOTFE. |
Mode |
Compatibility |
---|---|
ecb | Not supported by FreeOTFE. Note: This is a pretty insecure mode - the use of ECB is highly discouraged, and FreeOTFE is unlikely to ever support this mode. |
cbc-plain | Supported by FreeOTFE. |
cbc-essiv:<hash> | Supported by FreeOTFE |
xts-plain | Supported by FreeOTFE |
Hash |
Compatibility |
---|---|
sha1 | Supported by FreeOTFE. |
sha256 | Supported by FreeOTFE. |
sha512 | Supported by FreeOTFE. |
ripemd160 | Supported by FreeOTFE. |
If you do wish to read an ext2/ext3 formatted volume from MS Windows, the filesystem drivers listed below are suggested. There may well be others, though at time of writing (23rd December 2005) these are the only ones that I have checked:
Package |
URL |
Description |
---|---|---|
Ext2 Installable File System For Windows | http://www.fs-driver.org/ | Supports both read and write operations with ext2/ext3. Freeware, but closed source. |
EXT2 IFS for Windows | http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm | Supports ext2, readonly. Open source. |
Further information on Linux volumes may be obtained from:
Cryptoloop | Cryptoloop HOWTO |
loop-AES | loop-AES README |
dm-crypt | dm-crypt WWW site dm-crypt Wiki |
LUKS | LUKS - Linux Unified Key Setup |