[dm-crypt] detached LUKS header size

[dm-crypt] detached LUKS header size

[Fourhundred Thecat]

Hello,

I am using full-disk encryption with detached LUKS header.

The LUKS header file itself is stored on an initrd image which I boot
from USB, and then I decrypt the cryptsetup partition on my disk and
chroot into it.

The initrd system that I boot is very minimal, around 8MB in size.

The LUKS image, being 2MB, is making the initrd image needlessly bigger.

And the new LUKS2 format seems to use even larger header (10MB ?)

From what I understand, the keyslots themselves only use up 4KB of
space, and the rest is used for "antiforensic stripes".

This is probably a good idea when LUKS header is stored on disk together
with the cryptsetup partition.

But when using detached header, which is never stored on disk, this
makes less sense

Thus my question:

is it possible, somehow, to reduce the size of the LUKS header to
absolute minimum (4KB ?), when I don't need the antiforensic stripes ?

thank you,

Re: [dm-crypt] detached LUKS header size

[Arno Wagner]

If you do that, you kill the security model of LUKS.
The anti-forensic stripes are not some gadget, they
are central. Also, the key-slots are the stripes. There
are no 4kB you can take out and reconstruct the key
from them. 

That said, I think if you have an issue with 10MB extra 
today and are willing to sacrifice security to get rid
of them, then you are doing it massively wrong. Maybe
just do without encryption and security, it clearly is 
not your first priority....

Regards,
Arno




On Sat, Nov 23, 2019 at 06:43:56 CET, Fourhundred Thecat wrote:
> Hello,
> 
> I am using full-disk encryption with detached LUKS header.
> 
> The LUKS header file itself is stored on an initrd image which I boot
> from USB, and then I decrypt the cryptsetup partition on my disk and
> chroot into it.
> 
> The initrd system that I boot is very minimal, around 8MB in size.
> 
> The LUKS image, being 2MB, is making the initrd image needlessly bigger.
> 
> And the new LUKS2 format seems to use even larger header (10MB ?)
> 
> >From what I understand, the keyslots themselves only use up 4KB of
> space, and the rest is used for "antiforensic stripes".
> 
> This is probably a good idea when LUKS header is stored on disk together
> with the cryptsetup partition.
> 
> But when using detached header, which is never stored on disk, this
> makes less sense
> 
> Thus my question:
> 
> is it possible, somehow, to reduce the size of the LUKS header to
> absolute minimum (4KB ?), when I don't need the antiforensic stripes ?
> 
> thank you,
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://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] detached LUKS header size

[Milan Broz]

On 23/11/2019 06:43, Fourhundred Thecat wrote:
> Hello,
> 
> I am using full-disk encryption with detached LUKS header.
> 
> The LUKS header file itself is stored on an initrd image which I boot
> from USB, and then I decrypt the cryptsetup partition on my disk and
> chroot into it.
> 
> The initrd system that I boot is very minimal, around 8MB in size.
> 
> The LUKS image, being 2MB, is making the initrd image needlessly bigger.
> 
> And the new LUKS2 format seems to use even larger header (10MB ?)

Please read post to this list
https://marc.info/?l=dm-crypt&m=157146906003981&w=2
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932437#10

If you want, you can decrease size to be even smaller than LUKS1.

> 
>  From what I understand, the keyslots themselves only use up 4KB of
> space, and the rest is used for "antiforensic stripes".
> 
> This is probably a good idea when LUKS header is stored on disk together
> with the cryptsetup partition.
> 
> But when using detached header, which is never stored on disk, this
> makes less sense
> 
> Thus my question:
> 
> is it possible, somehow, to reduce the size of the LUKS header to
> absolute minimum (4KB ?), when I don't need the antiforensic stripes ?

AF is mandatory and must be there, but you can allocate only absolute minimum
for the LUKS2 whole header (for example only area for 1 keyslot), if you do not need other features.

Please see linka above.

If you need smaller header, do not use LUKS, but even VeraCrypt aligns header
to 128k - despite the using only the firsrt sector.
There is more magic than AF related, alignment on storage for example.

Thanks,
Milan

Re: [dm-crypt] detached LUKS header size

[Fourhundred Thecat]

On 23/11/2019 09.21, Arno Wagner wrote:
> If you do that, you kill the security model of LUKS.

Did you read my original post ?

I explaines, that the LUKS header is never stored on disk. What use are
antiforensic stripes, when LUKS header only exists in memory ?

> The anti-forensic stripes are not some gadget, they
> are central.

yes, when header is stored on disk.

> Also, the key-slots are the stripes. There
> are no 4kB you can take out and reconstruct the key
> from them.

> That said, I think if you have an issue with 10MB extra
> today and are willing to sacrifice security to get rid
> of them, then you are doing it massively wrong. Maybe
> just do without encryption and security, it clearly is
> not your first priority....

Actually, I believe my scheme is more secure than the default. My luks
header is detached and is stored encrypted on SD card, separate from the
disk. In plaintext form, it only exists in memory.

It is not that 10MB are unbearable. I just see no use in antiforensic
stripes when stored in memory.

Re: [dm-crypt] detached LUKS header size

[Arno Wagner]

On Sun, Nov 24, 2019 at 07:34:34 CET, Fourhundred Thecat wrote:
> On 23/11/2019 09.21, Arno Wagner wrote:
> > If you do that, you kill the security model of LUKS.
> 
> Did you read my original post ?

Yes.

> I explaines, that the LUKS header is never stored on disk. What use are
> antiforensic stripes, when LUKS header only exists in memory ?

You think memory is somehow immune to forensics and it cannot
go to disk? Here is news for you, in a virtualized situation
even locked memory may go to disk and there is nothing you
can do about it.

> > The anti-forensic stripes are not some gadget, they
> > are central.
> 
> yes, when header is stored on disk.

No. When using LUKS. If you want something else with a different
security model, do it yourself. It will not be LUKS though.

> > Also, the key-slots are the stripes. There
> > are no 4kB you can take out and reconstruct the key
> > from them.
> 
> > That said, I think if you have an issue with 10MB extra
> > today and are willing to sacrifice security to get rid
> > of them, then you are doing it massively wrong. Maybe
> > just do without encryption and security, it clearly is
> > not your first priority....
> 
> Actually, I believe my scheme is more secure than the default. 

No. That would require for LUKS to be insecure. 

But your model is less reliable, less flexible and more cumbersome
and does not have a careful, competent security analysis.

> My luks
> header is detached and is stored encrypted on SD card, separate from the
> disk. In plaintext form, it only exists in memory.

So?

> It is not that 10MB are unbearable. I just see no use in antiforensic
> stripes when stored in memory.

So you are willing to bank your security on your own security
analysis and request that others change a tool that has
stood the test of time so your own model can be 
implemented more easily?

Sorry, please go away and do your own thing by yourself.

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] detached LUKS header size

[Milan Broz]

On 24/11/2019 09:16, Arno Wagner wrote:
> 
> Sorry, please go away and do your own thing by yourself.

Arno,

please do not communicate with users this way.

This should be a friendly place, and it is normal that people disagree,
there is always some technical trade-offs (keeping AF in place is one of them).

And it is possible that in the future we can implement something better
based on these arguments and discussions.

But there is no room for ad hominem arguments.

Thank you,
Milan

Re: [dm-crypt] detached LUKS header size

[Michael Kjörling]

On 23 Nov 2019 06:43 +0100, from 400thecat@gmx.ch (Fourhundred Thecat):
> is it possible, somehow, to reduce the size of the LUKS header to
> absolute minimum (4KB ?), when I don't need the antiforensic stripes ?

If you consider LUKS' anti-forensic properties not just unnecessary
but actually significantly wasteful in your situation, as it appears
from your posts, you could use just plain dm-crypt; but do be aware of
its drawbacks compared to LUKS. There's good reason why plain
dm-crypt, or for that matter loop-AES, have largely fallen out of use.

You can in principle use plain dm-crypt with cryptsetup's --key-file
parameter to store the volume encryption key either completely
unsecured except for the fact that it's on different media, or secured
by other means; for example, the cryptsetup man page mentions the
possibility of using GnuPG for the purpose of securing the key file.

That way you can, again in principle, get the key file size down to
exactly however large the key for your chosen encryption algorithm is;
for example, for AES-256-XTS (512 bits' worth of volume key material)
the file could be as little as 64 bytes in size (plus any overhead
incurred by whatever method you use to secure it, if any).

It's important to keep in mind that anything like the above won't be
_LUKS_, so you should be very careful to not refer to it as LUKS.

Also, I offer _no guarantees whatsoever_ that this scheme will be
secure against any particular class of adversary or type of attack, or
even secure against _any_ adversary or attack. I am _only_ pointing
out that it is _technically possible to do_ and that it appears to
meet your stated need.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] detached LUKS header size

[Fourhundred Thecat]

On 23/11/2019 09.48, Milan Broz wrote:
>
> AF is mandatory and must be there, but you can allocate only absolute
> minimum
> for the LUKS2 whole header (for example only area for 1 keyslot), if you
> do not need other features.

Hi Milan,

if I decide to use luks1 format for my detached header, what size do I
need to allocate for the header file ?

From the FAQ on gitlab, it would seem luks1 needs 2MB header file
(Payload offset * 512), but when I use the "luksHeaderBackup" command on
an existing standard luks1 partition:

 cryptsetup luksHeaderBackup /dev/sde1 --header-backup-file sde1.header

it actually creates a file of size 1,052,672 bytes

Is this the complete luks header ?

If I want to minimize the size of LUKS header, without changing any
default settings, can I use a  1,052,672 bytes file for my luks1 header?

thank you,

Re: [dm-crypt] detached LUKS header size

[Milan Broz]

Hi,

On 25/11/2019 05:34, Fourhundred Thecat wrote:
> On 23/11/2019 09.48, Milan Broz wrote:
>>
>> AF is mandatory and must be there, but you can allocate only absolute
>> minimum
>> for the LUKS2 whole header (for example only area for 1 keyslot), if you
>> do not need other features.
> 
> Hi Milan,
> 
> if I decide to use luks1 format for my detached header, what size do I
> need to allocate for the header file ?

For LUKS1 you cannot modify header size, there is always 8 keyslots pre-allocated
and its size depends on stored key size (usually 128/256/512 bits).

Then there is alignment, so the real data offset is aligned by default to
the 1MB boundary.

With this padding, header size is for 128bit key 2MB, for 256/512 key 4MB.

(See table 5.2. in LUKS2 standard describing conversion from LUKS1
here https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf )

> 
>  From the FAQ on gitlab, it would seem luks1 needs 2MB header file
> (Payload offset * 512), but when I use the "luksHeaderBackup" command on
> an existing standard luks1 partition:
> 
>   cryptsetup luksHeaderBackup /dev/sde1 --header-backup-file sde1.header
> 
> it actually creates a file of size 1,052,672 bytes

So your header contains keyslots for 256bit keys.

The luksBackup should store the header without alignment, so it is the exact
used size (in this case 2056 512-byte sectors).

> Is this the complete luks header ?

Yes, it is full header without padding (for 256bit keys only!).

> If I want to minimize the size of LUKS header, without changing any
> default settings, can I use a  1,052,672 bytes file for my luks1 header?

Yes. For reference: for 128bit it is 528384 bytes, for 256bit 1052672 bytes,
for 512bit (2x256bits in XTS mode) it is 2068480 bytes.

Milan

Re: [dm-crypt] detached LUKS header size

[Fourhundred Thecat]

> On 2019-11-25 14:55, Milan Broz wrote:

Hi Milan,

just to make sure there is no misunderstanding:

> Then there is alignment, so the real data offset is aligned by default to
> the 1MB boundary.
>
> With this padding, header size is for 128bit key 2MB, for 256/512 key 4MB.

I am actually using 512 bit key:

 --cipher aes-xts-plain64 --key-size 512 --hash sha512

so it would seem I need 4MB header for luks1 with 512 key

> Yes. For reference: for 128bit it is 528384 bytes, for 256bit 1052672
> bytes,
> for 512bit (2x256bits in XTS mode) it is 2068480 bytes.

now I am confused. 2068480 is less than 2MB. So when aligned to 1MB
boundary, 2MB would be enough for luks1 with 512 key.

So is it 2MB or 4MB ?

many thanks,

Re: [dm-crypt] detached LUKS header size

[Milan Broz]

On 25/11/2019 16:17, Fourhundred Thecat wrote:
>> On 2019-11-25 14:55, Milan Broz wrote:
> 
> Hi Milan,
> 
> just to make sure there is no misunderstanding:
> 
>> Then there is alignment, so the real data offset is aligned by default to
>> the 1MB boundary.
>>
>> With this padding, header size is for 128bit key 2MB, for 256/512 key 4MB.
> 
> I am actually using 512 bit key:
> 
>   --cipher aes-xts-plain64 --key-size 512 --hash sha512
> 
> so it would seem I need 4MB header for luks1 with 512 key
> 
>> Yes. For reference: for 128bit it is 528384 bytes, for 256bit 1052672
>> bytes,
>> for 512bit (2x256bits in XTS mode) it is 2068480 bytes.
> 
> now I am confused. 2068480 is less than 2MB. So when aligned to 1MB
> boundary, 2MB would be enough for luks1 with 512 key.
> 
> So is it 2MB or 4MB ?

Ah, yes, sorry, it is 2MB. (The real used space is 4040 512-byte sectors.)

Milan