Main Page | Report this Page
 
   
Science Forum Index  »  Cryptography Forum  »  truecrypt equivalent with dm-crypt...
Page 1 of 1    
Author Message
Piergiorgio Sartor...
Posted: Mon Jul 21, 2008 3:45 pm
Guest
Hello,

I hope this is the correct NG to post such a question,
but I need some advice from experts about something is
"floating" in my mind.

I was playing around with some disk encryption tools,
namely truecrypt, dm-crypt and luks, and comparison
of features was, of course, happening.

So, truecrypt has, among other things, the possibility
to have cascade encryption and the encrypted header.

While truecrypt is also available under Linux, I was
wondering if it would be possible to create an equivalent
system using dm-crypt and luks.

The concept would be to use luks over a dm-crypt device,
which is over another dm-crypt device.

So, for example, let's say there is a disk, /dev/sdb.
Using dm-crypt something like /dev/mapper/level_1 is
created on top of /dev/sdb. Then this device is encrypted
again (with different algorithm) with dm-crypt and so
/dev/mapper/level_2 is created. Finally, this one becomes
the placeholder of a luks partition (third algorithm),
creating something which could be /dev/mapper/level_3.

This will have 3 cascaded encryption, plus the luks header
will be twice encrypted.

The first question is: does this make sense at all?
Especially considering that the luks header is somehow
known, opening the door to a known-plaintext attack.

The second question, assuming all the previous makes sense,
is: how about the encryption keys for the level_1 and level_2?

These should all be, in principle, derived from some
password, with "salting" and "iteration" (same password
for luks, of course).

A sub-question is: how to get the salt.

truecrypt uses a random 512 bits string, which is stored,
as far as I understood, unencrypted, in the first 64 bytes
of the header. So it is random, but known.
Of course it makes sense in order to hide the header, but
since it is known, does it need to be really random?

What about taking as salt the HD serial number? Or the
partition UUID? Or the partition size (assuming it will
not be changed)? Or else?

Any advice will be welcome!

Thanks a lot in advance,

bye,

--

piergiorgio
 
Page 1 of 1       All times are GMT - 5 Hours
The time now is Sat Nov 22, 2008 6:37 pm