1 |
On Tue, 8 Sep 2009 11:21:12 +0200 |
2 |
Marco <listworks@×××××.com> wrote: |
3 |
|
4 |
> I am about to encrypt my external hard drive. I found the howtos |
5 |
> http://de.gentoo-wiki.com/wiki/DM-Crypt and |
6 |
> http://de.gentoo-wiki.com/wiki/DM-Crypt/Daten-Partition_verschl%C3%BCsseln |
7 |
> (sorry, German...). They give a good understanding of how to do the |
8 |
> stuff, but I am unsure about which cipher to use. LRW is considered |
9 |
> insecure in some cases so thus it should be replaced by XTS which is |
10 |
> experimental though... Furthermore, if using XTS is used, there is |
11 |
> different options like xts-plain, xts-benbi, xts-essiv:sha256. Which |
12 |
> option is preferable? What about the key size? Is there any relation |
13 |
> between key size and block size of the file system in terms of data |
14 |
> security? |
15 |
|
16 |
|
17 |
I might be wrong here, since I'm not a crypto expert, so feel free to |
18 |
correct, but here's how I see it... |
19 |
|
20 |
|
21 |
From dm-crypt.c: |
22 |
|
23 |
Different IV generation algorithms: |
24 |
|
25 |
plain: the initial vector is the 32-bit little-endian version of the sector |
26 |
number, padded with zeros if neccessary. |
27 |
|
28 |
essiv: "encrypted sector|salt initial vector", the sector number is |
29 |
encrypted with the bulk cipher using a salt as key. The salt |
30 |
should be derived from the bulk cipher's key via hashing. |
31 |
|
32 |
benbi: the 64-bit "big-endian 'narrow block'-count", starting at 1 |
33 |
(needed for LRW-32-AES and possible other narrow block modes) |
34 |
|
35 |
null: the initial vector is always zero. Provides compatibility with |
36 |
obsolete loop_fish2 devices. Do not use for new devices. |
37 |
|
38 |
IV (Initialization Vector) is just a piece of random data to mix with |
39 |
stuff-to-encrypt for a disk block, so two blocks, encrypted by the same |
40 |
key won't look the same. Obviously, you need to know it to get the data |
41 |
back. |
42 |
Some sort of "salt" for a stream ciphers, but it doesn't get recorded |
43 |
anywhere, being calculated on-the-fly by one of the above methods. |
44 |
|
45 |
Note that 'always zero' approach would produce unsalted data, so not |
46 |
only the blocks can be identified, but also swapped - root-owned data |
47 |
can be pushed into some /tmp file (say, at night), which will be |
48 |
accessible by some malicious code after you'll enter the key. |
49 |
|
50 |
Plain and benbi seem to be simple counters, second one is probably just |
51 |
a multiple of the first, counting cipher blocks instead of disk blocks. |
52 |
These rule out the former case, but allow to write similar blocks of |
53 |
data, which can later be easily found on disk, especially if the length |
54 |
of data between them is known, since IV is absolutely predictable. |
55 |
|
56 |
ESSIV, on the other hand, uses the hash of these counters with the key |
57 |
itself to salt IV, so it seem to rule out all the aforementioned |
58 |
vulnerabilities. Hash strength here ensures that it can't be turned |
59 |
into former 'plain counters' case due to hash collision. |
60 |
|
61 |
|
62 |
XTS/LRW/CBC/... are methods to encrypt the single data block to a disk |
63 |
block. Since data is read in blocks, block also seem to be the atomic |
64 |
unit of data encryption - everything is en-/decrypted in whole blocks |
65 |
when read/written from/to disk. |
66 |
|
67 |
These methods further divide the disk block into a smaller units to |
68 |
ensure that there won't be a (similar to the above) case when two |
69 |
similar, say, 16-byte pieces in a single 512k disk block would look |
70 |
identical, otherwise some data with such watermarks can be generated |
71 |
and proven to be on this disk - whole blocks can be marked with them, |
72 |
so they can later be found, along with any known data between them. |
73 |
|
74 |
They also mix the key with some generated salt for these units. |
75 |
CBC relies on plain data, so it can be broken by crafted data. LRW also |
76 |
seem to suffer from some known vulnerabilities, so XTS seem to be the |
77 |
best and recommended one. |
78 |
|
79 |
|
80 |
And the first part of some definition like "serpent-lrw-benbi" is a |
81 |
cipher itself - the method of mixing the key with data, so they can't |
82 |
be easily separated. |
83 |
There are plenty of cipher benchmarks out there (openssl has one |
84 |
built-in) and the vulnerabilities are quite known. |
85 |
|
86 |
Rijndael, known as AES, being the standard, is very fast, but is a |
87 |
subject to all sort of scrutiny. |
88 |
Last thing I heard is that AES-256 is actually easier to break (although |
89 |
it hasn't gone that far) than AES-128, but that stuff can be easily |
90 |
found on a regular newsfeeds. |
91 |
|
92 |
|
93 |
-- |
94 |
Mike Kazantsev // fraggod.net |