Re: Re: Valid ciphers and modes for dmcrypt?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Normal disclaimer, I'm not educated in this field (:


Looking at http://en.wikipedia.org/wiki/XTS#XEX would make sense you
need a key twice as long, as there's two keys needed.


Regarding -h, man page seems to suggest that only applies to
cryptsetup create and not luksFormat.
Though the LUKS spec does say one could use any hash there, I presume
it's just not implemented yet.


dmsetup table will show you the 'master key' [MK] in luks terminology.

This is what happens when you luksFormat:

* Generate a random key MK and a random MK salt.
* Write MK salt in the LUKS header
* Ask user for password.
* Use PBKDF2 to convert password to key, using the MK salt. Encrypt MK
with this key.
* Write encrypted form of MK in a key slot,

[Dunno the exact order of things]

Just to be clear: The MK is what your disk is encrypted with. Your
password is used to encrypt the MK.

If you run cryptsetup luksFormat again you'll see the MK change.
luksAddkey on the other hand won't change the MK but instead will fill
a key slot with another encrypted copy of the MK.

The whole point of all this is so you can have multiple passwords that
unlock the one volume and so you can change passwords without having
to re encrypt the entire volume.



On Sat, May 24, 2008 at 11:52 AM, domiel <domiel42@xxxxxxxxxxxx> wrote:
> Yet more experimentation... :-)
>
> Seems that I've solved my original problem;
> looking at the output from cat /proc/cypto it seems that the minimum keylength
> is doubled when using twofish with either lrw or xts vs plain.
>
> So all that needs doing is to double the keylength.
>
> However now I have some more questions from my further experiments:
>
> if you use the crypsetup command the -h option seems to do nothing; no matter
> what is passed in as the hash algorithm if you do a dmsetup table --showkey
> the resulting key is always the same, I was under the impression that the key
> passed in is hashed against the chosen algorithm to become the actual key used
> by the chosen cipher... is this correct?
>
> when I tried the Luks extensions the chosen hash still seems to have no impact
> and doing a luksDump always shows the hash as sha1, no matter what is passed in
>
> also the output of luksDump shows an entry of "MK salt" how is this determined?
>
> Again, any help in understanding this stuff is most appreciated.
>
>
> ---------------------------------------------------------------------
> dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
> To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
> For additional commands, e-mail: dm-crypt-help@xxxxxxxx
>
>

---------------------------------------------------------------------
dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/
To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx
For additional commands, e-mail: dm-crypt-help@xxxxxxxx


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux