[dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

Happy holidays everybody,

I am trying to create a LUKS volume with a detached header that has
data offset at sector 256 and things fail with
 an error that reads:

"Data offset for detached LUKS header must be either 0 or higher than
header size (4036 sectors)."

Is there a technical reason why this is so and is it possible to allow
other data offsets?

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.

Everything seems to be working except for the data offset since i cant
set it to 256 sectors through the library API.

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Arno Wagner]

On Tue, Dec 22, 2015 at 13:00:08 CET, .. ink .. wrote:
> Happy holidays everybody,
> 
> I am trying to create a LUKS volume with a detached header that has
> data offset at sector 256 and things fail with
>  an error that reads:
> 
> "Data offset for detached LUKS header must be either 0 or higher than
> header size (4036 sectors)."
> 
> Is there a technical reason why this is so and is it possible to allow
> other data offsets?

No idea. What about doing an offset with LVM first and then zero
offset for LUKS?
 
> 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.

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...

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

Regards,
Arno

> Everything seems to be working except for the data offset since i cant
> set it to 256 sectors through the library API.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

> 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

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Arno Wagner]

On Tue, Dec 22, 2015 at 16:39:48 CET, .. ink .. wrote:
[...]
> >> 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.

I agree. Thanks for the info, will try that.

> > 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.

Also good to know. I think I will make it easier on me and just
decrypt, then recrypt with TrueCrypt and use VeraCrypt on that
volume. Takes longer but is 5 minutes of actuial work. 

> 
> > 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].

That was my impression as well. Maybe in a year or two they
will have something.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Milan Broz]

On 12/22/2015 01:00 PM, .. ink .. wrote:
> Happy holidays everybody,
> 
> I am trying to create a LUKS volume with a detached header that has
> data offset at sector 256 and things fail with
>  an error that reads:
> 
> "Data offset for detached LUKS header must be either 0 or higher than
> header size (4036 sectors)."
> 
> Is there a technical reason why this is so and is it possible to allow
> other data offsets?

The reason was that it allows header to copy back to the LUKS device.
(Or create a fake header :)

TBH this is the first time I see someone want to use it for Veracrypt
device, I can fix the code to allow it but not sure if this is really
worth to do it.

You can probably write a script that will modify final mapping using
dmsetup (but that's quite a hack). Also simple program should be able
to reformat header to downgrade the header (keep keys and cipher chain).

But wouldn't be better just to use old TrueCrypt modes here from
the beginning?

Milan


> 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.
> 
> Everything seems to be working except for the data offset since i cant
> set it to 256 sectors through the library API.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

> You can probably write a script that will modify final mapping using
> dmsetup (but that's quite a hack). Also simple program should be able
> to reformat header to downgrade the header (keep keys and cipher chain).
>

Its possible to create the mapper directly using only dmsetup but the
problem is managing the
master key i extracted from VeraCrypt volume and i though a detached
LUKS header would be adequate in holding it and protect it with a
passphrase.

> But wouldn't be better just to use old TrueCrypt modes here from
> the beginning?
>

My advise to people is to continue to use TrueCrypt volumes and crank
up the passphrase quality.

The problem here is that it is somebody else's VeraCrypt volume and i
am using it enough times to be annoyed by its delays and i thought of
looking into ways of by passing it.

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

I managed to change the sources of version 1.7.0 to make it accept 256
sector data offset and a bit more "research" into what i am trying to
do and it doesnt look like its possible to "sneak in" a VeraCrypt
volume as a LUKS volume because VeraCrypt volumes starts their IV
offset at 256 sectors where as LUKS volumes starts their IV offset at
0.

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Arno Wagner]

On Tue, Dec 22, 2015 at 21:31:29 CET, .. ink .. wrote:
> I managed to change the sources of version 1.7.0 to make it accept 256
> sector data offset and a bit more "research" into what i am trying to
> do and it doesnt look like its possible to "sneak in" a VeraCrypt
> volume as a LUKS volume because VeraCrypt volumes starts their IV
> offset at 256 sectors where as LUKS volumes starts their IV offset at
> 0.

Maybe the --skip option will help here? 

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

> Maybe the --skip option will help here?
>

The option is not available with LUKS volumes and the following error
message is produced when it is used when unlocking a LUKS volume:

cryptsetup: Option --skip is supported only for open of plain and
loopaes devices.

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Arno Wagner]

Hmm. What about actually shifting the partition contents physically?

Or maybe have a dummy-LUKS device, open that, read the master-key 
(see FAQ Item 6.10 ) close it again, and use that master-key
on a plain device? This is probably far to complex, but could 
serve for experiments.

Regards,
Arno

On Wed, Dec 23, 2015 at 07:15:37 CET, .. ink .. wrote:
> > Maybe the --skip option will help here?
> >
> 
> The option is not available with LUKS volumes and the following error
> message is produced when it is used when unlocking a LUKS volume:
> 
> cryptsetup: Option --skip is supported only for open of plain and
> loopaes devices.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

> Hmm. What about actually shifting the partition contents physically?
>
The current problem is not on the data offset,but it is on IV offset.

LUKS API allows setting of data offset and i got it to accept 256
sector offset by removing the
current restriction that forces the offset to be either zero or larger
that header
size.

Currently,LUKS API does not have an option to set IV offset and my problem would
be solved if the API is introduced.

> Or maybe have a dummy-LUKS device, open that, read the master-key
> (see FAQ Item 6.10 ) close it again, and use that master-key
> on a plain device? This is probably far to complex, but could
> serve for experiments.
>

My understanding the API documentation says a pre-generated master key
can be used
with "crypt_format" only with LUKS volumes.

Once the master key and other info are known,the best way to do it is to create
the mapper straight using dmsetup. I can already do this but the
problem with doing
it this way or through plain device is in the management of the master
key and i was
hoping that a detached LUKS header will be able to manage it for me.

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Milan Broz]

On 12/23/2015 09:39 AM, .. ink .. wrote:
>> Hmm. What about actually shifting the partition contents physically?
>>
> The current problem is not on the data offset,but it is on IV offset.
> 
> LUKS API allows setting of data offset and i got it to accept 256
> sector offset by removing the
> current restriction that forces the offset to be either zero or larger
> that header
> size.

Yes but LUKS header does not have attribute for storing IV offset.
New format will allow it, so we can think about using the new header
as "a generic key storage".
(In fact if there is enough space on device we can convert the device metadata
in-place. But that's future...)
 
> Currently,LUKS API does not have an option to set IV offset and my problem would
> be solved if the API is introduced.

I really do not want to workaround problems in other software by introducing
hacks in current version of LUKS.

If you really want this, you can use existing API (open LUKS device/header,
get volume key, open device again in PLAIN mode and use the parameters).
Should be few lines of code.

Milan

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

> I really do not want to workaround problems in other software by introducing
> hacks in current version of LUKS.
>

I agree and will probably settle with having a local patched version
of cryptsetup.

Making progress on this front as i can now unlock a volume with
offsets VeraCrypt volumes expects.

[root@ink mtz]# cryptsetup luksOpen veraCrypt.img --header=header.img rrr
Enter passphrase for veraCrypt.img:

[root@ink mtz]# dmsetup table /dev/mapper/rrr
0 40704 crypt aes-xts-plain64 -master-key- 256 7:0 256

[root@ink mtz]# blkid /dev/mapper/rrr
/dev/mapper/rrr: SEC_TYPE="msdos" UUID="706E-EE80" TYPE="vfat"
[root@ink mtz]#


> If you really want this, you can use existing API (open LUKS device/header,
> get volume key, open device again in PLAIN mode and use the parameters).
> Should be few lines of code.
>

Like i said earlier,PLAIN volumes do not use crypt_format argument for
the master key[1]

[1] https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/setup.c#L1090

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Milan Broz]

On 12/23/2015 01:10 PM, .. ink .. wrote:
>> I really do not want to workaround problems in other software by introducing
>> hacks in current version of LUKS.
>>
> 
> I agree and will probably settle with having a local patched version
> of cryptsetup.
> 
> Making progress on this front as i can now unlock a volume with
> offsets VeraCrypt volumes expects.
> 
> [root@ink mtz]# cryptsetup luksOpen veraCrypt.img --header=header.img rrr
> Enter passphrase for veraCrypt.img:
> 
> [root@ink mtz]# dmsetup table /dev/mapper/rrr
> 0 40704 crypt aes-xts-plain64 -master-key- 256 7:0 256
> 
> [root@ink mtz]# blkid /dev/mapper/rrr
> /dev/mapper/rrr: SEC_TYPE="msdos" UUID="706E-EE80" TYPE="vfat"
> [root@ink mtz]#
> 
> 
>> If you really want this, you can use existing API (open LUKS device/header,
>> get volume key, open device again in PLAIN mode and use the parameters).
>> Should be few lines of code.
>>
> 
> Like i said earlier,PLAIN volumes do not use crypt_format argument for
> the master key[1]

Sure, but activate_by_volume_key can be used here.

m.

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[.. ink ..]

On Wed, Dec 23, 2015 at 9:23 AM, Arno Wagner <arno@wagner.name> wrote:
>
> Hmm. What about actually shifting the partition contents physically?
>
> Or maybe have a dummy-LUKS device, open that, read the master-key
> (see FAQ Item 6.10 ) close it again, and use that master-key
> on a plain device? This is probably far to complex, but could
> serve for experiments.
>

This actually works and i will go with it,it is actually possible to
get the master key
from a header without first unlocking the device.

I have a proof of concept code on how to get a master key from a LUKS
volume/header
and then opening a plain dm-crypt device with the master key together
with other options.

I have used the code to successfully create a LUKS volume header with
a VeraCrypt
master key and then reading the master key from the LUKS header and
create a "correct"
mapper through a plain dm-crypt device.

The code is at:
https://github.com/mhogomchungu/random_stuff/blob/master/cryptsetup.c

Re: [dm-crypt] Variable data offset for a LUKS volume that uses a detached header.

[Arno Wagner]

On Wed, Dec 23, 2015 at 23:15:51 CET, .. ink .. wrote:
> On Wed, Dec 23, 2015 at 9:23 AM, Arno Wagner <arno@wagner.name> wrote:
> >
> > Hmm. What about actually shifting the partition contents physically?
> >
> > Or maybe have a dummy-LUKS device, open that, read the master-key
> > (see FAQ Item 6.10 ) close it again, and use that master-key
> > on a plain device? This is probably far to complex, but could
> > serve for experiments.
> >
> 
> This actually works and i will go with it,it is actually possible to
> get the master key
> from a header without first unlocking the device.
> 
> I have a proof of concept code on how to get a master key from a LUKS
> volume/header
> and then opening a plain dm-crypt device with the master key together
> with other options.
> 
> I have used the code to successfully create a LUKS volume header with
> a VeraCrypt
> master key and then reading the master key from the LUKS header and
> create a "correct"
> mapper through a plain dm-crypt device.

Excellent, that was the idea. The actual dummy-mapping was 
only for the case that you use the cryptsetup binary, with
the library that is not needed. "Plain" as the actual 
maping for the data-device has the advantage that you
get a lot more flexibility.
 
> The code is at:
> https://github.com/mhogomchungu/random_stuff/blob/master/cryptsetup.c

Thanks for sharing!

Reagrds,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier