On Fri, January 23, 2015 22:33, Ahmed, Safayet (GE Global Research) wrote:
> I've been looking into the cryptsetup tool and I just wanted to mention
> some
> bugs/undocumented features I came across.
>
> 1 detached headers
> ------------------
>
> For a Luks setup that uses a detached header, a lot of the cryptsetup
> commands
> don't work in an intuitive way. Specifically, the "--header" option is
> ignored
> and cryptsetup throws an error that the specified device is not a Luks
> device.
> The cryptsetup commands work when the path to the actual luks device is
> replaced with the path to the header file. This was the case for the
> following
> commands:
>
> luksDump
> luksAddKey
> luksKillSlot
>
> I didn't check for the other commands. If this is the intended behavior, I
> think it should be mentioned in the doucmentation that the header file
> should
> be used in place of the <device> argument in the case of detached LUKS
> headers.
Operations on the HEADER naturally require the header and not the actual
payload. It would be redundant to pass the payload (device) and naturally
the header is the only (direct) parameter. Should this be mentioned more
clearly in the docs/manpage? Possibly yes.
>
>
> 2 master-key-file with new-key-file
> -----------------------------------
>
> For the luksAddKey command, when the "--master-key-file" argument is
> specified,
> the new-key-file positional argument is ignored. Whether or not a file is
> provided for the new pass phrase, the user is prompted to enter a pass
> phrase.
I think I reported this quite a while back and it was supposedly fixed
some while ago (2010 IIRC).
>
> The problem is in the implementation of the function "action_luksAddKey"
> in
> "src/cryptsetup.c". Consider the following lines (916 - 927):
>
> if (opt_master_key_file) {
> r = _read_mk(opt_master_key_file, &key, keysize);
> if (r < 0)
> goto out;
> //FIXME: process keyfile arg
> r = crypt_keyslot_add_by_volume_key(cd, opt_key_slot,
> key, keysize, NULL, 0);
> } else if (opt_key_file || opt_new_key_file) {
> r = crypt_keyslot_add_by_keyfile_offset(cd, opt_key_slot,
> opt_key_file, opt_keyfile_size, opt_keyfile_offset,
> opt_new_key_file, opt_new_keyfile_size, opt_new_keyfile_offset);
> } else {
>
> When the master key is present, the code doesn't check "opt_new_key_file"
> and
> assumes that the user should be prompted for the pass phrase.
>
> Is this the intended behavior of luksAddKey?
>
> regards,
>
> Safayet Ahmed
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
>
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
