[pkg-cryptsetup-devel] Bug#924560: Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi Dimitri,

On Thu, 14 Mar 2019 at 12:36:13 +0000, Dimitri John Ledkov wrote:
> Currently the new cryptsetup defaults to LUKS2 format with the
> following parameters:
> 
> Default PBKDF for LUKS2: argon2i
> Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4

The actual parameters used for the KDF are determined by benchmark upon
luksFormat (or luksAddKey).  See cryptsetup(8):

--pbkdf <PBKDF spec>
    […]

    Note that increasing memory cost also increases time, so the final
    parameter values are measured by a benchmark. The benchmark tries to
    find iteration time (--iter-time) with required memory cost
    --pbkdf-memory. If it is not possible, the memory cost is decreased
    as well. The parallel cost --pbkdf-parallel is constant, is is
    checked against available CPU cores (if not available, it is
    decreased) and the maximum parallel cost is 4.

> For example many IoT and Pi devices have 1GB of ram in total, and thus
> would OOM kill when trying to luksOpen.

Is that something you experienced?  I just deployed a fresh a Debian sid
VM with 2vCPUs, 1GiB RAM a default encryption stack (LVM2 on top of
LUKS/dm-crypt).  Works just fine :-)  The actual memory cost is about
half of the physical memory.

    $ cryptsetup luksDump /dev/vda5 | grep -Fe "Time cost:" -e "Memory:" -e "Threads:"
	Time cost:  4
	Memory:     505372
	Threads:    2

    $ dd if=/dev/zero of=/tmp/disk.img bs=1M count=64
    $ printf test | cryptsetup luksFormat --debug --key-file=- /tmp/disk.img
    […]
    # Running argon2i() benchmark.
    # PBKDF benchmark: memory cost = 32, iterations = 4, threads = 2 (took 2 ms)
    # PBKDF benchmark: memory cost = 512, iterations = 4, threads = 2 (took 1 ms)
    # PBKDF benchmark: memory cost = 8192, iterations = 4, threads = 2 (took 18 ms)
    # PBKDF benchmark: memory cost = 113777, iterations = 4, threads = 2 (took 233 ms)
    # PBKDF benchmark: memory cost = 122078, iterations = 4, threads = 2 (took 234 ms)
    # PBKDF benchmark: memory cost = 130425, iterations = 4, threads = 2 (took 249 ms)
    # PBKDF benchmark: memory cost = 130948, iterations = 4, threads = 2 (took 251 ms)
    # PBKDF benchmark: memory cost = 505422, iterations = 8, threads = 2 (took 2015 ms)
    # Benchmark returns argon2i() 8 iterations, 505422 memory, 2 threads (for 512-bits key).
    […]
    Command successful.

    $ printf test | cryptsetup luksOpen --debug --key-file=- /tmp/disk.img crypt_disk
    […]
    # Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
    # Not enough physical memory detected, PBKDF max memory decreased from 1048576kB to 505422kB.
    # PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb 505422, parallel_threads 2.
    […]
    Command successful.

Works equally fine on a VM with 512MiB RAM.  There the memory cost is
set to ~250MiB.

> Please consider reducing the default memory requirement of the argon2i
> in luks2 by default, or switching to pbkdf2 for LUKS2 as well.

I think diverging from upstream (and other distros) with respect to
default algorithms requires careful consideration.  And in that case,
compared to PBKDF2 Argon2 has interesting properties (such as resistance
to GPU cracking) which would be a shame not to benefit from out of the
box.

> I think it is unfortunate to not support default encryption on 1GB big
> devices and VMs.

AFAICT it does.  What I guess doesn't is if the machine's resources are
significantly reduced between luksFormat/luksAddKey and luksOpen.

OTOH parallel unlocking might be an issue indeed, especially if the
devices are unlocked in an unattended fashion (for instance via key
files).  That said on my 1GiB VM I could reliably boot with

    $ cat /etc/crypttab 
    root_crypt /dev/vda4  none                luks
    swap_crypt /dev/vda2  /etc/keys/swap.key  luks,swap
    home_crypt /dev/vda3  /etc/keys/home.key  luks

(root_crypt being unlocked an initramfs stage, the other two later by
systemd) and

    $ cat /etc/fstab 
    /dev/vda1               /boot  ext2  defaults  0  2
    /dev/mapper/swap_crypt  none   swap  sw        0  0
    /dev/mapper/root_crypt  /      ext4  defaults  0  1
    /dev/mapper/home_crypt  /home  ext4  defaults  0  2

However the OOM killer does trigger when I add a third volume.  I guess
the boot process is racy and might, or might not, abort depending on
what's being started at the same time.  But I'd argue that setup is far
from a typical installation, and the same goes for low-memory devices
with plenty of encrypted disks attached.  (Moreover Debian's default
initramfs implementation comes from initramfs-tools, where unlocking is
sequential.  So root-device encryption is out of the picture.)

Having a separate encrypted /home partition (unlocked by systemd)
doesn't seem to cause any problem when formatted with the default
parameters, which I understood is what this bug report is about.

Cheers,
-- 
Guilhem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20190314/35a524f1/attachment.sig>