1 |
Hi Mike, |
2 |
|
3 |
Thanks for your very detailed description and explanation! |
4 |
|
5 |
On Wed, Sep 9, 2009 at 12:30 PM, Mike Kazantsev<mk.fraggod@×××××.com> wrote: |
6 |
> On Tue, 8 Sep 2009 11:21:12 +0200 |
7 |
> Marco <listworks@×××××.com> wrote: |
8 |
|
9 |
[...] |
10 |
|
11 |
> ESSIV, on the other hand, uses the hash of these counters with the key |
12 |
> itself to salt IV, so it seem to rule out all the aforementioned |
13 |
> vulnerabilities. Hash strength here ensures that it can't be turned |
14 |
> into former 'plain counters' case due to hash collision. |
15 |
> |
16 |
> |
17 |
> XTS/LRW/CBC/... are methods to encrypt the single data block to a disk |
18 |
> block. Since data is read in blocks, block also seem to be the atomic |
19 |
> unit of data encryption - everything is en-/decrypted in whole blocks |
20 |
> when read/written from/to disk. |
21 |
> |
22 |
> These methods further divide the disk block into a smaller units to |
23 |
> ensure that there won't be a (similar to the above) case when two |
24 |
> similar, say, 16-byte pieces in a single 512k disk block would look |
25 |
> identical, otherwise some data with such watermarks can be generated |
26 |
> and proven to be on this disk - whole blocks can be marked with them, |
27 |
> so they can later be found, along with any known data between them. |
28 |
> |
29 |
> They also mix the key with some generated salt for these units. |
30 |
> CBC relies on plain data, so it can be broken by crafted data. LRW also |
31 |
> seem to suffer from some known vulnerabilities, so XTS seem to be the |
32 |
> best and recommended one. |
33 |
|
34 |
So I think I'll go with xts-essiv:sha256. In terms of performance, a |
35 |
keylength of 256 might not be ideal. But since this external drive is |
36 |
mainly thought as a backup device,this is not too much of a drawback. |
37 |
|
38 |
-- |
39 |
Best regards, |
40 |
Marco |