Re: Two questions about LUKS2 format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@xxxxxxxxxxx
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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux