[dm-crypt] dm-crypt overhead

[dm-crypt] dm-crypt overhead

[Lukáš Pohanka]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

I have a couple of questions regarding dm-crypt and overhead when using
different encryption algorithms.

Firstly, am I right that the aes-xts-plain64 algorithm has no overhead,
i.e. the size occupied at the target device is exactly the same as it would
be without the dm-crypt layer?

Secondly, when using aes-gcm, is the authentication tag created per-sector?
This means in this case there is an overhead per each sector (depending on
the tag size)?

Also I couldn't find how the IV is calculated in case of aes-gcm, can also
-plain64 be used?

Thanks in advance for clarifications.

Lukas

[-- Attachment #2: Type: text/html, Size: 707 bytes --]

Re: [dm-crypt] dm-crypt overhead

[Milan Broz]

On 03/01/2018 03:24 PM, Lukáš Pohanka wrote:
> I have a couple of questions regarding dm-crypt and overhead when using different encryption algorithms.
> 
> Firstly, am I right that the aes-xts-plain64 algorithm has no overhead, i.e. the size occupied at the target device is exactly the same as it would be without the dm-crypt layer?
> 
> Secondly, when using aes-gcm, is the authentication tag created per-sector? This means in this case there is an overhead per each sector (depending on the tag size)?
> 
> Also I couldn't find how the IV is calculated in case of aes-gcm, can also -plain64 be used?
> 
> Thanks in advance for clarifications.

Hi Lukas,

all default FDE modes are length-preserving, so there is no additional per-sector metadata space, so it cannot use AEAD.

With LUKS2 I introduced authenticated encryption (still experimental) where you can use some authenticated modes,
but there are many limitations for now.

For the basic info see my FOSDEM slides
https://fosdem.org/2018/schedule/event/cryptsetup/

and release notes for cryptsetup2
https://www.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes

Most of your questions should be answered there.

(There is some paper submitted regarding this, I hope I can make it public soon, or mail me privately.)

Milan

Re: [dm-crypt] dm-crypt overhead

[Lukáš Pohanka]

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

Hi Milan,

thanks for clarifications. Unfortunately, we are currently constrained to
use only dmsetup and cannot provision the target device with cryptsetup.
Thus we cannot use LUKS, only plain dm-crypt.
Hopefully it will change in the future. However, does this mean there is
currently no chance of using any form of authenticated encryption in our
case?

Thanks,
Lukas

2018-03-01 15:42 GMT+01:00 Milan Broz <gmazyland@gmail.com>:

> On 03/01/2018 03:24 PM, Lukáš Pohanka wrote:
> > I have a couple of questions regarding dm-crypt and overhead when using
> different encryption algorithms.
> >
> > Firstly, am I right that the aes-xts-plain64 algorithm has no overhead,
> i.e. the size occupied at the target device is exactly the same as it would
> be without the dm-crypt layer?
> >
> > Secondly, when using aes-gcm, is the authentication tag created
> per-sector? This means in this case there is an overhead per each sector
> (depending on the tag size)?
> >
> > Also I couldn't find how the IV is calculated in case of aes-gcm, can
> also -plain64 be used?
> >
> > Thanks in advance for clarifications.
>
> Hi Lukas,
>
> all default FDE modes are length-preserving, so there is no additional
> per-sector metadata space, so it cannot use AEAD.
>
> With LUKS2 I introduced authenticated encryption (still experimental)
> where you can use some authenticated modes,
> but there are many limitations for now.
>
> For the basic info see my FOSDEM slides
> https://fosdem.org/2018/schedule/event/cryptsetup/
>
> and release notes for cryptsetup2
> https://www.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes
>
> Most of your questions should be answered there.
>
> (There is some paper submitted regarding this, I hope I can make it public
> soon, or mail me privately.)
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 2582 bytes --]

Re: [dm-crypt] dm-crypt overhead

[Michael Kjörling]

On 1 Mar 2018 15:59 +0100, from numberfour@seznam.cz (Lukáš Pohanka):
> However, does this mean there is currently no chance of using any
> form of authenticated encryption in our case?

You could use a validating file system (such as ZFS or Btrfs) with a
plainly encrypted container. An adversary would then need to alter the
correct data block, plus the metadata block that holds the checksum
for the data block. Depending on the specific file system architecture
this could require correctly altering blocks all the way to the root
structures ("superblocks") of the file system. That might be good
enough even if authenticated encryption is unavailable.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] dm-crypt overhead

[Milan Broz]

On 03/01/2018 03:59 PM, Lukáš Pohanka wrote:
> thanks for clarifications. Unfortunately, we are currently
> constrained to use only dmsetup and cannot provision the target
> device with cryptsetup. Thus we cannot use LUKS, only plain
> dm-crypt. Hopefully it will change in the future. However, does this
> mean there is currently no chance of using any form of authenticated
> encryption in our case?

Hi,

you can use it just with dmsetup, but there are several steps that
are not obvious (for example formatting dm-integrity device requires
two steps etc).
But it is definitely something I would not suggest :-)

So in general (I intentionally do not want to paste exact commands,
you have to be sure what you are doing here):

- you will need recent-enough kernel (4.12+)

Formatting (only once):
- prepare block device, wipe first megabytes with zeroes
- activate dm-integrity device (using dm-setup) with size 8 sectors,
and with proper parameters (mainly tag size per sector) you need (do not use internal hash)
- deactivate dm-integrity device

(Steps above will format the device in-kernel, writing integrity superblock.)

Later use (normal activation):
- activate dm-integrity device with proper data size (read from dm-integrity
superblock). (In future it will be simpler.)
- activate dm-crypt device with proper parameters above the dm-itegrity device
(with proper authentication mode parameters, tag size, random IV etc)

- Profit. (Use top-level dm-crypt device as usual.)

(You should probably overwrite the whole device using direct-io on the first
activation to initialize auth.tags.
Otherwise any reads, including page cache, will fail on -EILSEQ - integrity error.)

The above is in principle what crypstestup is doing for you.

Authenticated filesystem is definitely better idea, but because I can
guess in which environment you are trying to implement
this I guess it is not an option...

Milan

Re: [dm-crypt] dm-crypt overhead

[Lukáš Pohanka]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

Milan,

thank you very much for a useful and informative answer. I'll have a look
at this.

Maybe I have a one more question: which part requires the 4.12+ kernel?

I'm afraid I'll have to backport the changes if we decide to proceed.

Thanks again,
Lukas

2018-03-01 18:41 GMT+01:00 Milan Broz <gmazyland@gmail.com>:

> On 03/01/2018 03:59 PM, Lukáš Pohanka wrote:
> > thanks for clarifications. Unfortunately, we are currently
> > constrained to use only dmsetup and cannot provision the target
> > device with cryptsetup. Thus we cannot use LUKS, only plain
> > dm-crypt. Hopefully it will change in the future. However, does this
> > mean there is currently no chance of using any form of authenticated
> > encryption in our case?
>
> Hi,
>
> you can use it just with dmsetup, but there are several steps that
> are not obvious (for example formatting dm-integrity device requires
> two steps etc).
> But it is definitely something I would not suggest :-)
>
> So in general (I intentionally do not want to paste exact commands,
> you have to be sure what you are doing here):
>
> - you will need recent-enough kernel (4.12+)
>
> Formatting (only once):
> - prepare block device, wipe first megabytes with zeroes
> - activate dm-integrity device (using dm-setup) with size 8 sectors,
> and with proper parameters (mainly tag size per sector) you need (do not
> use internal hash)
> - deactivate dm-integrity device
>
> (Steps above will format the device in-kernel, writing integrity
> superblock.)
>
> Later use (normal activation):
> - activate dm-integrity device with proper data size (read from
> dm-integrity
> superblock). (In future it will be simpler.)
> - activate dm-crypt device with proper parameters above the dm-itegrity
> device
> (with proper authentication mode parameters, tag size, random IV etc)
>
> - Profit. (Use top-level dm-crypt device as usual.)
>
> (You should probably overwrite the whole device using direct-io on the
> first
> activation to initialize auth.tags.
> Otherwise any reads, including page cache, will fail on -EILSEQ -
> integrity error.)
>
> The above is in principle what crypstestup is doing for you.
>
> Authenticated filesystem is definitely better idea, but because I can
> guess in which environment you are trying to implement
> this I guess it is not an option...
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 2962 bytes --]

Re: [dm-crypt] dm-crypt overhead

[Arno Wagner]

Hi LUkas,

sounds like you are in a really dysfunctional (security-wise)
corporate environment. Maybe your time would be better
spend trying to fix that...

Regards,
Arno

On Thu, Mar 01, 2018 at 22:20:36 CET, Lukáš Pohanka wrote:
>    Milan,
>    thank you very much for a useful and informative answer. I'll have a
>    look at this.
>    Maybe I have a one more question: which part requires the 4.12+ kernel?
>    I'm afraid I'll have to backport the changes if we decide to proceed.
>    Thanks again,
>    Lukas
> 
>    2018-03-01 18:41 GMT+01:00 Milan Broz <[1]gmazyland@gmail.com>:
> 
>      On 03/01/2018 03:59 PM, Lukáš Pohanka wrote:
>      > thanks for clarifications. Unfortunately, we are currently
>      > constrained to use only dmsetup and cannot provision the target
>      > device with cryptsetup. Thus we cannot use LUKS, only plain
>      > dm-crypt. Hopefully it will change in the future. However, does
>      this
>      > mean there is currently no chance of using any form of
>      authenticated
>      > encryption in our case?
>      Hi,
>      you can use it just with dmsetup, but there are several steps that
>      are not obvious (for example formatting dm-integrity device requires
>      two steps etc).
>      But it is definitely something I would not suggest :-)
>      So in general (I intentionally do not want to paste exact commands,
>      you have to be sure what you are doing here):
>      - you will need recent-enough kernel (4.12+)
>      Formatting (only once):
>      - prepare block device, wipe first megabytes with zeroes
>      - activate dm-integrity device (using dm-setup) with size 8 sectors,
>      and with proper parameters (mainly tag size per sector) you need (do
>      not use internal hash)
>      - deactivate dm-integrity device
>      (Steps above will format the device in-kernel, writing integrity
>      superblock.)
>      Later use (normal activation):
>      - activate dm-integrity device with proper data size (read from
>      dm-integrity
>      superblock). (In future it will be simpler.)
>      - activate dm-crypt device with proper parameters above the
>      dm-itegrity device
>      (with proper authentication mode parameters, tag size, random IV
>      etc)
>      - Profit. (Use top-level dm-crypt device as usual.)
>      (You should probably overwrite the whole device using direct-io on
>      the first
>      activation to initialize auth.tags.
>      Otherwise any reads, including page cache, will fail on -EILSEQ -
>      integrity error.)
>      The above is in principle what crypstestup is doing for you.
>      Authenticated filesystem is definitely better idea, but because I
>      can
>      guess in which environment you are trying to implement
>      this I guess it is not an option...
>      Milan
> 
> References
> 
>    1. mailto:gmazyland@gmail.com

> _______________________________________________
> 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] dm-crypt overhead

[Milan Broz]

On 03/01/2018 10:20 PM, Lukáš Pohanka wrote:
> Milan,
> 
> thank you very much for a useful and informative answer. I'll have a look at this.
> 
> Maybe I have a one more question: which part requires the 4.12+ kernel?
> 
> I'm afraid I'll have to backport the changes if we decide to proceed.

Well, Arno guessed right that it a case in a big corporate ... :-)

I would definitely not suggest to try backport this, it will be very time consuming
and you will need to follow many fixes later (it is new code, it will have problems).
The code itself is in device-mapper subsystem, but there probably other fixes elsewhere
that need to be backported as well (block layer - integrity support, crypto API AEAD etc).

On the other side, I would welcome any feedback of using this kind of encryption
on practical cases or even in industrial systems. Even it means massive backports.

Milan