[Question] Distinction responsibilities LUKS and dm-crypt

[Question] Distinction responsibilities LUKS and dm-crypt

[Surmont Jasper]

Dear, keep in mind I’m fairly new to Linux kernel development and
similar, so my question might sound stupid. 
 
Reading through the documentation of both dm-crypt and LUKS, 
I understand that LUKS is a format specification 
to allow FDE, and that dm-crypt is a dm target which allows
encryption / decryption of writes / reads to the block device. 

However, I'm unsure about
what each of these now exactly provides (ie what are the responsibilities). In
the slides  (look link at the bottom) that the author (Milan Broz) made,
it mentions that LUKS2 can also provide integrity protection (hence making the
encryption authenticated). From this, and also reading the Luks1 specification
I think this is not possible in LUKS1. However, later in the slides it talks
how dm-crypt allows for authenticated encryption. This is where I'm confused;
do we assume we use LUKS2? 

I feel like I'm not really grasping the main function and responsibilities of both LUKS and dm-crypt. 
Thanks! 
 
Slides: https://archive.fosdem.org/2018/schedule/event/cryptsetup/attachments/slides/2506/export/events/attachments/cryptsetup/slides/2506/fosdem18_cryptsetup_aead.pdf 
 
Sincerely, Jasper Surmont  

Re: [Question] Distinction responsibilities LUKS and dm-crypt

[Christoph Anton Mitterer]

dm-crypt/dm-verity are the kernel drivers doing the actual encryption
verification.
As is e.g. md* for Linux DM software raid.


LUKS is a container format keeping data like encrypted keys or
integrity data... as well as space for some operations like device re-
encrypt.
As is the "mdadm container" (not sure whether this has an official
name... I mean the containers with version 0, 0.90, 1, 1.0, 1.1, 1.2)
for Linux DM software raid.

You could have e.g. encryption without LUKS (which has some pros and
"cons" - mostly pros, I'd say)... because one encrypted block maps
exactly to one decrypted block.
You can't have integrity protection/AEAD without a special disk format
OR extra device... as the integrity data needs to go somewhere.

cryptsetup/veritysetup are the userland tools allowing to manage the
above.
As mdadm would be for Linux DM software raid.


Cheers,
Chris.


On Thu, 2022-03-31 at 18:21 +0000, Surmont Jasper wrote:
> Dear, keep in mind I’m fairly new to Linux kernel development and
> similar, so my question might sound stupid. 
>  
> Reading through the documentation of both dm-crypt and LUKS, 
> I understand that LUKS is a format specification 
> to allow FDE, and that dm-crypt is a dm target which allows
> encryption / decryption of writes / reads to the block device. 
> 
> However, I'm unsure about
> what each of these now exactly provides (ie what are the
> responsibilities). In
> the slides  (look link at the bottom) that the author (Milan Broz)
> made,
> it mentions that LUKS2 can also provide integrity protection (hence
> making the
> encryption authenticated). From this, and also reading the Luks1
> specification
> I think this is not possible in LUKS1. However, later in the slides
> it talks
> how dm-crypt allows for authenticated encryption. This is where I'm
> confused;
> do we assume we use LUKS2? 
> 
> I feel like I'm not really grasping the main function and
> responsibilities of both LUKS and dm-crypt. 
> Thanks! 
>  
> Slides:
> https://archive.fosdem.org/2018/schedule/event/cryptsetup/attachments/slides/2506/export/events/attachments/cryptsetup/slides/2506/fosdem18_cryptsetup_aead.pdf
>  
>  
> Sincerely, Jasper Surmont  
> 

Re: [Question] Distinction responsibilities LUKS and dm-crypt

[Christoph Anton Mitterer]

On Thu, 2022-03-31 at 18:56 +0000, Surmont Jasper wrote:
> So, would I be correct to write that the ability to have
> authenticated encryption depends on the underlying storage format
> (where eg LUKS1 does not support it, and LUKS2 does)?

Well practically (as of now), yes,... but that's more from an
engineering PoV.
You simply need some place where the integrity data is stored - with
cryptsetup+AEAD this is done within the LUKS2 container (not supported
with LUKS1)... but if you use dm-verity alone, there is no LUKS and the
integrity data is stored in an extra (hash_)device.


> You also mentioned encryption without LUKS has more pros than cons.

Oops,... I've meant the otherway round: it's in nearly all cases better
to use LUKS.


> so what are the main advantages of using something else than LUKS?

The "else" is only plain dm-dmcrypt devices (i.e. no meta-data stored
on disk)... unless you count 3rd party formats in like bitlocker.

Some people may say that with "plain" you get some level of plausible
deniability - i.e. you could say there is no encrypted data on the
device.
Whether that works out in practise is another question - I'd kinda
doubt that the <random evil country>-torturer would believe you, if
you'd insist that you've filled some good parts of your device with
seemingly random data just for the fun of it.

It may have some tiny advantages when using it for temporary devices
(like temporarily encrypted swap devices).


Cheers,
Chris.

Re: [Question] Distinction responsibilities LUKS and dm-crypt

[Michael Kjörling]

On 31 Mar 2022 21:32 +0200, from calestyo@scientia.org (Christoph Anton Mitterer):
> Some people may say that with "plain" /.../
> /.../
> It may have some tiny advantages when using it for temporary devices
> (like temporarily encrypted swap devices).

For that use case I would prefer to say that using LUKS has no added
benefit over a plain dm-crypt mapping, because the key material would
be thrown away on a reboot anyway. (Effectively giving swap the same
largely-emphemeral storage properties as RAM.) You _can_ do the same
thing by reformatting a LUKS container before passing it to swapon(8),
but doing so has no significant benefit that I can see compared to
just re-opening a plain dm-crypt mapping with a key read each time
from /dev/{u,}random and treating any pre-existing data as garbage.

Another use case for plain dm-crypt mappings is when you want to
pre-fill a storage device with random data to conceal which parts are
in use by what's inside a LUKS container: my experience is that it's
much faster to open a dm-crypt mapping with a throwaway key and then
write from /dev/zero through it, than is writing from /dev/{u,}random
to the raw backing device, and absent the key the output of any
competent encryption algorithm _should_ be indistinguishable from
random anyway. But maybe with the up-and-coming changes to
/dev/{u,}random in Linux that'll be subject to change.

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

Re: [Question] Distinction responsibilities LUKS and dm-crypt

[Arno Wagner]

First, dm-crypt is the base-mechanism on block-layer.
There is a "plain dm-crypt" encryption mechanism in 
cryptsetup, sometimes abbreviated as "dm-crypt". 
This ione comes with no meta-data. You enter a paword
and if you do not use the default parameters, you state 
them as well each time you open the device.

LUKS adds a header with metadata, possibilities to use
more passwords and use non-default settings withouth
having to state them each time. But LUKS basically only
does a more elaborate set-up and then passes the actual
work on to dm-crypt. 

I hope that clears up some of the confusuion.

Regards,
Arno




On Thu, Mar 31, 2022 at 20:21:00 CEST, Surmont Jasper wrote:
> Dear, keep in mind I’m fairly new to Linux kernel development and
> similar, so my question might sound stupid. 
>  
> Reading through the documentation of both dm-crypt and LUKS, 
> I understand that LUKS is a format specification 
> to allow FDE, and that dm-crypt is a dm target which allows
> encryption / decryption of writes / reads to the block device. 
> 
> However, I'm unsure about
> what each of these now exactly provides (ie what are the responsibilities). In
> the slides  (look link at the bottom) that the author (Milan Broz) made,
> it mentions that LUKS2 can also provide integrity protection (hence making the
> encryption authenticated). From this, and also reading the Luks1 specification
> I think this is not possible in LUKS1. However, later in the slides it talks
> how dm-crypt allows for authenticated encryption. This is where I'm confused;
> do we assume we use LUKS2? 
> 
> I feel like I'm not really grasping the main function and responsibilities of both LUKS and dm-crypt. 
> Thanks! 
>  
> Slides: https://archive.fosdem.org/2018/schedule/event/cryptsetup/attachments/slides/2506/export/events/attachments/cryptsetup/slides/2506/fosdem18_cryptsetup_aead.pdf 
>  
> Sincerely, Jasper Surmont  

-- 
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: [Question] Distinction responsibilities LUKS and dm-crypt

[Michael Kjörling]

On 31 Mar 2022 18:21 +0000, from jasper.surmont@aalto.fi (Surmont Jasper):
> Reading through the documentation of both dm-crypt and LUKS, 
> I understand that LUKS is a format specification 
> to allow FDE, and that dm-crypt is a dm target which allows
> encryption / decryption of writes / reads to the block device. 
> 
> However, I'm unsure about
> what each of these now exactly provides (ie what are the responsibilities).

Consider the simple case: a plain dm-crypt mapping that uses typical,
non-authenticated, length-preserving (when used for amounts of data
that is a multiple of the block size) encryption.

That gets you encryption, but the encryption metadata (algorithm, key
size, block size, cipher mode, key, ...) must be kept elsewhere,
because there's no room for it within the container itself (because if
there were, the mapping wouldn't be length-preserving). Maybe some of
it, such as the key, is derived from a passphrase provided by the
user, but then you need somewhere to store metadata on _how_ the
transformation from a passphrase to a cryptographic key is performed.
So suppose that, instead of relying solely on the user to memorize
such details, you allow for keeping it in a configuration file
somewhere. Maybe call it /etc/crypttab.

That's still moderately inconvenient, especially when /etc and the
container lives on different media, because the two work in tandem;
one is meaningless without the other. So suppose instead that we were
to reserve a small chunk out of the container itself to hold that
metadata. The encryption can still be length-preserving, but we accept
that the usable size of the container is slightly less than its total
size on the outside, because this metadata requires some non-zero
amount of storage space; just like how we accept that creating a file
system on a volume costs a non-zero amount of storage space out of
that volume in order to provide greater flexibility in its usage. Now
the container itself can hold enough information that it's usable
without any external knowledge that would change from one container to
the next, other than the passphrase.

That latter is basically what LUKS 1 does.

As well as what LUKS 2 does.

There are of course many, many more details to _how_ it's done in
order to make it both secure and usable in practice, but that should
give you a reasonable picture of the different responsibilities
between dm-crypt itself and LUKS.

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