Re: [dm-crypt] Cascading two plain dm-crypt volumes

[Matthias Schniedermeyer <ms@citd.de>]

On 29.11.2013 01:32, anderson jackson wrote:
> Hello, 
> 
> I have a small question regarding luks and plain dm-crypt, and I am unsure
> what to use. 
> 
> I feel that the advantages provided by Luks obviously offers extra security
> compared to plain, however I feel uneasy about the obviousness of the fact
> that the drive is encrypted. Mainly because a disk with just random data could
> have been wiped instead of encrypted. I would like the extra security provided
> by luks without it being obvious that the disk is encrypted. To combat this I
> was thinking about doing a cascade of two identical ciphers in plain mode, in
> this case AES because the AES-NI acceleration will severely limit the
> performance penalty of cascading two ciphers, I had the following setup in
> mind:
> 
> first step: cryptsetup ???-cipher=aes-xts-plain ???-offset=0 ???-key-size=512
> open ???-type=plain /dev/sdx cascade1, with the first independend password.
> Second step: cryptsetup ???-cipher=aes-xts-plain ???-offset=0 ???-key-size=512
> open ???-type=plain /dev/mapper/cascade1 cascade2, with the second independed
> unrelated password.
> Third step: nwipe --rounds=1 --noblank --prng=twister --method=random
> /dev/mapper/cascade2, this will fill the last block device with random data to
> completely fill up the entire disk. 
> Fourth step: format the last block device with ext4.
> 
> My theory then is, that even when an attacker finds the first passwords, he
> will never know he has because the result will be random just as with a wrong
> password. In fact all possible passwords will result in random data. The
> attacker has no way of knowing if there are cascades and how many. Am I right
> to come to this conclusion or should I stick with luks and deal with it being
> an obvious encrypted disk?

There is also loop-aes v3 format, also supported by dm-crypt/cryptsetup.
It doesn't use a header and you need a total of 65 keys to be 
broken, before you could read the whole volume.
But you would need to use a key-file to store the 65 keys, the 
"standard" method is to use gpg for that.
Without the key-file it is pratically impossible to break such an 
encrypted volume. Same as it is pratically impossible to break a simple 
plain encrypted volume with a key that has full entophy.




-- 

Matthias