Hi everyone,
I've played around with lots of the new stuff in cryptsetup 2.0 (except
AEAD) a little bit and encountered some weird behavior.
First of all I don't claim to be an expert and some of the behaviour I'm
going to describe may well be intended and/or my own fault. So please
excuse and correct any false assumptions I might have made.
For one I just wanted to play with it a bit, so I couldn't be bothered
to setup a working compile environment. So I used just used the Debian
experimental packages and the dependencies which are required in newer
versions than were already installed on the up-to-date Ubuntu 16.04 test
machine.
That's why I'd be rather happy if someone with a properly compiled and
working trunk version could (in)validate my findings.
Some of the dodgy behaviour might be because of this, but certainly not
all of it.
A short description of the underlying system (idling the whole time) and
the partitioning scheme:
- Athlon X2 6000+ (2 cores @ 3000MHz); 8GB of RAM
- 4k aligned gpt partition created with parted:
sudo parted --align optimal /dev/sdd
in parted:
- create GPT partition table with "mklabel gpt"
- create partition of maximum size with minimal free space at
beginning and end for alignment: "mkpart primary 0% 100%"
- check if alignment of the partition we just created is
correct: "align-check optimal 1"
- exit parted with "quit"
But first I have a question related to the mailing list:
How is it possible that the dm-crypt mailing list web interace and admin
panel can't be accessed via a secure TLS or at least some broken old
SSL connection? As in: can somebody please fix this?
The following comments refer to varitions of this command, but I
verified most of my findings by using only minimal options in addition
to those which seemed to have caused the issues:
"sudo cryptsetup luksFormat --type luks2 --verbose -q /dev/sdd1
--use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512
--label DATA_crypt --subsystem "" --key-file keyfile"
The keyfile is just a bit of randomness from /de/urandom.
1. The output of "sudo luksDump /dev/sdd1" looks pretty ok, except that
Argon2i uses only the absolute minimum amount of RAM 131072 KiB/128MiB.
I read in one of Milans last posts on this list that --iteration-time
takes precedence over the memory setting. But as I used the default
options with 8GB of RAM I would have expected something way more in line
with the examples on parameter choice from the IRTF Argon Draft paper
(p. 12f).
2. luksFormat fails with -1 if aes-xts-essiv is used
This is probably expected, but I wanted to mention it anyways, as a poor
mans version of the ESSIV+random IV Milan mused about in
http://www.saout.de/pipermail/dm-crypt/2017-December/005778.html
Anyways: is there something I can do to use aes-xts-essiv as a slight
improvement over aes-xts-plain64? Or is this a stupid idea altogether?
The following comments refer to using --pbkdf argon2id --iter-time 2500
--pbkdf-memory 1048576 --pbkdf-parallel 4 in additon to the settings
from the example above:
3. Why does cryptsetup luksFormat allow at max 1048576kb (~1GB) of
memory usage for Argon2? This seems incredibly low compared to the
parameter choice recommendations from the Argon2 RFC draft. Even if you
don't use those as defaults, why would you ever set an upper limit which
is way below the recommendations?
4. Similar to the memory setting the thread count seems to be capped at
the number of processor cores, even tough the IRTF Argon Draft paper
explicitly uses twice the amount of cores in ALL examples on parameter
choice. Again, this might be acceptable as a default, but why is it a
hard limit? Even if there is a good reason to do so (I can't imagine
one), why is the user input silently ignored instead of throwing an
error as with the memory setting?
5. No matter if I explicitly force the use of Argon2i or Argon2id,
digests are still hardcoded to use pbkdf2.
6. However it seems much more concerning to me that only 1000 rounds of
pbkdf2 are applied to digests when --pbkdf-force-iterations is used
(independent of --pbkdf parameter).
7. I did encounter some silent failures in my first tests (luksFormat
finished fine, but device couldn't be mounted later) when using high
values for --iter-time (working: up to ~2500, definately failing:
5000-10000) or --pbkdf-force-iterations (working: up to ~4, definately
failing: 10, 12). However this was before I swapped the existing 6 GB of
normal RAM with 8GB of ECC RAM. This might either be explained by the
RAM beeing faulty or the lower amount. But as I couldn't verify this
anymore today, I won't bother you with more details on this.
Other comments:
8. From the ML:
I [Milan Broz] disagree with Argon2id as a default [decision by Argon2
authors]. [...] So final parameter set was decision after some test runs
on real systems.
Could you please elaborate on your decision? I couldn't notice any
performance issues with Argon2id in my (admittedly few) tests and I
personally don't feel that the default values should be so far removed
from the recommendations of the original authors who explicitly favor
Argon2id in an FDE scenario.
Together with the low defaults and especially the upper limits for
--pbkdf-memory and --pbkdf-parallel this doesn't really inspire
confidence. At the very least the reasoning which lead to the choice of
those defaults requires a coherent explanation in the man page.
The upper limits are a mystery to me tough and make me feel patronized.
Even if choosing too big values would make cryptsetup crash this would
at least be the consequence of a free decision of a (hopefully) informed
user. Nobody prevents me from rm -rf / either.
9. On luksDump output format:
- "Time:" below PBKDF algorithm seems to match the PBKDF iterations
instead of --iter-time...this should probably be renamed. This only
applies to Argon2, it's already called Iterations when using PBKDF2.
10. This is obviously a minor nitpick but it seems cryptsetup benchmark
still uses the 800ms default which afair was bumped up to 2000 as OOM
killer prevention. It would be nice if the default values were also used
for the benchmark.
11. The default numbers for --pbkdf-memory compared with the
defaults/minimums claimed on this list (e.g. 131072 kB vs 128MB) don't
match up, which seems to indicate Kibibytes, and Mebibytes were meant.
However kilobytes is used in the manpage and output. Could you enlighten
me if the base unit is actually kB or KiB?
Kind regards
curve25519
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
