[dm-crypt] Two questions about LUKS2 format
arno at wagner.name
Fri Dec 29 21:45:21 CET 2017
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
> 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.
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at 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
More information about the dm-crypt