[dm-crypt] [PATCH] Speed up keyfile reading

Michael Kjörling michael at kjorling.se
Sun Aug 13 15:16:13 CEST 2017

On 13 Aug 2017 08:34 -0400, from angelomariafederichini191269 at protonmail.com (angelomariafederichini191269):
>> How big is that keyfile? (And what is underlying storage?)
>> Just wonder why it is so slow...
> The keyfile size is the maximum allowed by cryptsetup so its 8MB.
> The storage is sometimes a tmpfs, i.e., RAM, and sometimes a SSD.

It _does_ indeed appear to take excessively long when using a huge key

$ dd if=/dev/urandom bs=1 count=6000000 | base64 --wrap=0 > keyfile
6000000+0 records in
6000000+0 records out
6000000 bytes (6,0 MB) copied, 14,9171 s, 402 kB/s
$ stat --printf='%s\n' keyfile
$ truncate -s 100M backing
$ sudo -i
# losetup -f --show backing
# time cryptsetup luksFormat -c aes-xts-plain64 --key-size 512 --key-file keyfile --iter-time 1 --batch-mode /dev/loop0

real   0m32.832s
user   0m1.756s
sys    0m30.666s
# time cryptsetup luksFormat -c aes-xts-plain64 --key-size 512 --key-file keyfile --iter-time 30000 --batch-mode /dev/loop0

real   1m40.155s
user   1m8.384s
sys    0m30.258s

Curiously, I see no significant difference when doing this with
backing storage being rotational HDDs in RAID6 (RAIDZ2, to be precise)
or with SSDs in RAID1 (actually a ZFS two-way mirror). If anything, it
seems to be a tiny bit _faster_ when reading the key file off of
spinning rust. I didn't try off a tmpfs or ramfs.

Of course, one could (and frankly, I'd be inclined to) argue that you
gain nothing by having a huge key file. Even if you are worried about
the entropy of whatever you used to generate the key file, a few
hundred bytes should be _more_ than enough, seeing as it is being
condensed down to at most 512 bits (64 bytes) -- in the case of XTS
with 2x256 bits of key -- that need to be as random as possible.

If your key file is so poorly generated that it really only contains
about 0.000008 bits of actual randomness per byte, you should be
generating it in some other manner. If you are really worried,
increase the key derivation iteration time a bit. No need to go as
extreme as I did above (which I only did to isolate the system
execution time); a few seconds ought to be more than enough unless you
are on a horribly underpowered system and have very powerful
adversaries A.K.A. your threat model includes nation-state actors who
would attack the key file without simply forcing you to reveal the
key. Which, as is so eloquently illustrated by <https://xkcd.com/538>,
isn't a terribly likely scenario.

Michael Kjörling • https://michael.kjorling.semichael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

More information about the dm-crypt mailing list