Re: Variable data offset for a LUKS volume that uses a detached header.

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

 



> No idea. What about doing an offset with LVM first and then zero
> offset for LUKS?
>

Already tried that and it didnt work(for my atleast)

dmsetup output of a properly created VeraCrypt mapper looks like this:

0 40448 crypt aes-xts-plain64 --master-key-- 256 7:0 256

I did what you suggested before i wrote to the list by creating a
linear dm device with 256 sector offset by running:

dmsetup create qqq --table "0 40448 linear /dev/loop0 256"

Creating a dm crypt mapper on the above mapper at zero offset produces
the following dmsetup output:

0 40448 crypt aes-xts-plain64 --master-key-- 0 253:0 0

So,this suggestion doesnt work and i think the reason is that the
third option from right is the IV initial sector number and it must be
256 and it cant be hidden through stacking up dm devices(i think).

>> Reason for doing this is an attempt at having a detached LUKS header
>> capable of unlocking a VeraCrypt volume since
>> unlocking a VeraCrypt volume takes too long and its annoying.
>
> Oh, yes. I did complain to them, never got an answer. I plan
> to move my Windows machine back to the last Truecrypt, since
> the one known vulnerability seems not to affect single-user
> machines anyways.
>

Recent versions of VeraCrypt has an option to default to TrueCrypt
volumes when unlocking
and hence you can use it the same way you use TrueCrypt and because of this,i
think its better to continue to use VeraCrypt with the option set to
use it as if its TrueCrypt.

You can set the option at: menu->settings->preferences->mount
options->TrueCrypt mode.

> Currently I am attaching 8 zeros to the pasphrase, so I can unlock
> my high-entropy passhrase with iteration 10 and not wait 70 seconds
> in VeraCrypt. Somebody there really has no clue why usability is
> important and that users should be able to ovverride most things.
> They may just know more than the developers about their application
> scenario...
>

zuluCrypt can create VeraCrypt volumes with a PIM value of 1 and a
blank password as minimum
requirements.

> Does anybody know what the status of CipherShed and TCnext is and
> whether they have more of a clue?
>

I peek at their mailing lists at a rate of about once a month and i do
not think they are going
anywhere anytime soon[1].

[1] https://lists.ciphershed.org/pipermail/devs/2015-November/001209.html
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[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