[dm-crypt] Two questions about LUKS2 format

[dm-crypt] Two questions about LUKS2 format

[Geo Kozey]

1. When creating new container with experimental ciphers, i.e. chacha20, the output of luksDump shows:

Data segments:
  0: crypt
        offset: 4194304 [bytes]
        length: (whole device)
        cipher: chacha20-random
        sector: 512 [bytes]
        integrity: poly1305

Keyslots:
  0: luks2
        Key:        256 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        PBKDF:      argon2i
        Time cost:  4

Why "Cipher: aes-xts-plain64" is shown under Keyslots metadata and is different than "cipher: chacha20-random" from Data segments?

2. What happens when we create new luks container with argon2 as PBKDF under system with huge amount of RAM then try opening it under system with much lower amount (so memory cost will be higher than physical memory available)? Will it open but slower or will it fail?

Thanks in advance for any answers.

Yours sincerely

G. K.

Re: [dm-crypt] Two questions about LUKS2 format

[Milan Broz]

On 12/29/2017 05:41 PM, Geo Kozey wrote:
> 1. When creating new container with experimental ciphers, i.e. chacha20, the output of luksDump shows:
> 
> Data segments:
>   0: crypt
>         offset: 4194304 [bytes]
>         length: (whole device)
>         cipher: chacha20-random
>         sector: 512 [bytes]
>         integrity: poly1305
> 
> Keyslots:
>   0: luks2
>         Key:        256 bits
>         Priority:   normal
>         Cipher:     aes-xts-plain64
>         PBKDF:      argon2i
>         Time cost:  4
> 
> Why "Cipher: aes-xts-plain64" is shown under Keyslots metadata and is different than "cipher: chacha20-random" from Data segments?

The keyslot encryption cannot use AEAD directly (in fact keyslots are
already authenticated through key digest check).

For now I just hardcoded aes-xts-plain64 algorithm there, forgot to
mention it in release notes, sorry.
So if you use AEAD, keyslot will use aes-xts, if you use
length-preserving encryption (as in LUKS1), keyslot will use the same
algorithm as for data.

(The on-disk format allows per slot encryption setting but commandline
would bee too complicated - we can add options for it it later though.)

> 2. What happens when we create new luks container with argon2 as PBKDF under system with huge amount of RAM then try opening it under system with much lower amount (so memory cost will be higher than physical memory available)? Will it open but slower or will it fail?

It will unfortunately fail (it is behavior of libargon2 internals, but
even if is able to use swap, it would slow down unlocking drastically.
It is memory-hard function by definition so it behaves this way...).
Actually it can even trigger OOM killer and kill cryptsetup itself.

This is something we will need to tune-in in practise - nobody actually
started to use Argon2 this way and in academic papers it always work and
usually ignored because it is implementation detail ;-)

So, if you plan to use LUKS2 on device with very low memory later, you
have to add some slot with adequate low setting.
(If you format it there, it should decrease memory according to physical
available memory automatically.)
You can also have now one slot using Argon2 and another PBKDF2, but this
will obviously degrade resistance to brute force on GPUs etc.

Anyway, thanks for testing and questions!

Milan

Re: [dm-crypt] Two questions about LUKS2 format

[Arno Wagner]

Hi,

On Fri, Dec 29, 2017 at 17:41:11 CET, Geo Kozey wrote:
> 1. When creating new container with experimental ciphers, i.e. chacha20, the output of luksDump shows:
> 
> Data segments:
>   0: crypt
>         offset: 4194304 [bytes]
>         length: (whole device)
>         cipher: chacha20-random
>         sector: 512 [bytes]
>         integrity: poly1305
> 
> Keyslots:
>   0: luks2
>         Key:        256 bits
>         Priority:   normal
>         Cipher:     aes-xts-plain64
>         PBKDF:      argon2i
>         Time cost:  4
> 
> Why "Cipher: aes-xts-plain64" is shown under Keyslots metadata and is different than "cipher: chacha20-random" from Data segments?

Interesting. I assume the cipher in the keyslot is the one used
in the AF protection? In the old header there was no cipher-spec
for the keyslot, things were hard-coded.


> 2.  What happens when we create new luks container with argon2 as PBKDF
> under system with huge amount of RAM then try opening it under system with
> much lower amount (so memory cost will be higher than physical memory
> available)?  Will it open but slower or will it fail?

Interesting question. I would think that it should not open by
default and instead give an error. The rationale for that would
be that if memory is low enough, it could get so much slower that
people would assume it is broken. That is never good.

It may be a good idea to have an option --ignore-insufficient-kdf-memory 
in addition, with a warning that things can get catastrophically slow,
i.e. may take years or longer.

Incidentally, I will start a LUKS2 FAQ section when I find the
time.Questions like these are a good starting point.

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] Two questions about LUKS2 format

[Arno Wagner]

Ah, I see, both already answered.

Regards,
Arno

On Fri, Dec 29, 2017 at 18:10:53 CET, Milan Broz wrote:
> On 12/29/2017 05:41 PM, Geo Kozey wrote:
> > 1. When creating new container with experimental ciphers, i.e. chacha20, the output of luksDump shows:
> > 
> > Data segments:
> >   0: crypt
> >         offset: 4194304 [bytes]
> >         length: (whole device)
> >         cipher: chacha20-random
> >         sector: 512 [bytes]
> >         integrity: poly1305
> > 
> > Keyslots:
> >   0: luks2
> >         Key:        256 bits
> >         Priority:   normal
> >         Cipher:     aes-xts-plain64
> >         PBKDF:      argon2i
> >         Time cost:  4
> > 
> > Why "Cipher: aes-xts-plain64" is shown under Keyslots metadata and is different than "cipher: chacha20-random" from Data segments?
> 
> The keyslot encryption cannot use AEAD directly (in fact keyslots are
> already authenticated through key digest check).
> 
> For now I just hardcoded aes-xts-plain64 algorithm there, forgot to
> mention it in release notes, sorry.
> So if you use AEAD, keyslot will use aes-xts, if you use
> length-preserving encryption (as in LUKS1), keyslot will use the same
> algorithm as for data.
> 
> (The on-disk format allows per slot encryption setting but commandline
> would bee too complicated - we can add options for it it later though.)
> 
> > 2. What happens when we create new luks container with argon2 as PBKDF under system with huge amount of RAM then try opening it under system with much lower amount (so memory cost will be higher than physical memory available)? Will it open but slower or will it fail?
> 
> It will unfortunately fail (it is behavior of libargon2 internals, but
> even if is able to use swap, it would slow down unlocking drastically.
> It is memory-hard function by definition so it behaves this way...).
> Actually it can even trigger OOM killer and kill cryptsetup itself.
> 
> This is something we will need to tune-in in practise - nobody actually
> started to use Argon2 this way and in academic papers it always work and
> usually ignored because it is implementation detail ;-)
> 
> So, if you plan to use LUKS2 on device with very low memory later, you
> have to add some slot with adequate low setting.
> (If you format it there, it should decrease memory according to physical
> available memory automatically.)
> You can also have now one slot using Argon2 and another PBKDF2, but this
> will obviously degrade resistance to brute force on GPUs etc.
> 
> Anyway, thanks for testing and questions!
> 
> Milan
> _______________________________________________
> 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