Arch Linux

SeagullFish

Member

Registered: 2023-08-10

Posts: 80

[SOLVED] try-empty-password= option in /etc/crypttab

Hello.

I have 2 questions related to the man page for /etc/crypttab, regarding encrypted volumes with empty passwords.

try-empty-password=

Takes a boolean argument. If enabled, right before asking the user for a password it is first attempted to unlock the volume with an empty password. This is useful for systems that are initialized with an encrypted volume with only an empty password set, which shall be replaced with a suitable password during first boot, but after activation.
Added in version 246.

Q1: What is the proper procedure to create such a volume?

I have created a test-volume in a regular file like this:

$ sudo mkdir /test
$ sudo dd bs=1M count=20 if=/dev/urandom of=/test/volume.img

Lumo suggests the following procedure:

# 1. Create a volume with a temporary password
cryptsetup luksFormat --type luks /test/volume.img

# 2. Add a key file (e.g. with empty contents)
dd bs=1 count=0 if=/dev/zero of=/test/keyfile.key
cryptsetup luksAddKey /test/volume.img /test/keyfile.key

# 3. Remove the original password slot
cryptsetup luksRemoveKey /test/volume.img

By lack of better knowledge, I don’t see anything wrong with this approach. But I am not sure if this approach may cause the errrors mentioned under Q2.

Q2: What cryptsetup command should be executed to unlock such a volume?

The description on the man page is obviously intended for usage by systemd at boot time. However, I assume that systemd actually never unlocks volumes by itself, but rather invokes cryptsetup to do the job. If that assumption is right, it should be possible to figure out the exact cryptsetup command that the option try-empty-password=true will execute.

Lumos suggestion:

$ sudo cryptsetup open --key-file /test/keyfile.key /test/volume.img myvolume

This actually unlocks the volume, but in this case I consider that I am unlocking it with the key file, and not with an empty password as is the use case described in the man page. I interpret the term «trying with an empty password» to mean unlocking with a zero-length passphrase, without the need for a key file. Of course one could argue that I could simply change the command to prompt for a password, and then press ENTER without typing any password when prompted:

$ sudo cryptsetup open /test/volume.img myvolume
Enter passphrase for /test/volume.img:

This also actually unlocks the volume, but it requires involving a human user, and will therefore not be applicable inside of a shell script or other software code that is supposed to unlock the volume automatically. If such automation is impossible, and a human user needs to be involved anyway, then I don't see the point of having the option try-empty-password= in the first place.

My suggestion, and result:

$ sudo cryptsetup open --key-file /dev/null /test/volume.img myvolume
Nothing to read on input.

As you can see, my suggestion fails. Lumo states (responding to my suggestion) that:

It is worth mentioning some caveates:
- Version differences: Older versions of cryptsetup may have a minimum length of key files (--keyfile-size), which can cause lengths of 0 bytes to be rejected. You may optionally override with --keyfile-size 1 or remove the limitation.
- Device type: /dev/null is a character unit, not a regular file. Most versions of cryptsetup will handle this fine, but there is no 100 % guarantee across all platforms.
In short: The command should work and is actually a pretty elegant way to test the consept without needing a physical key file. If it fails, the --keyfile-size parameter is the first you should look at.

Adding the option --keyfile-size 1 to the command makes no difference. I get the same result regardless.

Last edited by SeagullFish (2026-08-09 17:49:01)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,651

Re: [SOLVED] try-empty-password= option in /etc/crypttab

Empty passphrase is after all a bit unusual. Seems like it's not supported particularly well.

--key-file does not like /dev/null or empty input from pipe so `printf "" | cryptsetup open` does not work (Nothing to read on input).

--key-file /dev/zero --keyfile-size 0 also does not work because 0 is interpreted as "unlimited". --keyfile-size 1 is one byte and thus not empty so it won't work unless you set a single-byte key.

You can use `printf "\n" | cryptsetup open ...` which somehow passes since something could be read (just a newline) and in this mode, newlines are seen as terminator, so the actual input is still empty. This does not work for --key-file since newlines in key files are actually part of the key.

You'd have to make another 0-byte file (`touch somenewfile`) or set --keyfile-offset to the filesize in bytes (so it actually reads 0 bytes from the file) but that's very counter-intuitive.

Personally I never set the "emtpy" passphrase. I have a system where passphrase is changed during boot in initramfs, but its not changed from an empty one, just a random / known key phrase.

systemd / crypttab has its own interface, it does not actually use cryptsetup CLI utility, so it does not translate.

Last edited by frostschutz (2026-08-09 16:50:22)

SeagullFish

Member

Registered: 2023-08-10

Posts: 80

Re: [SOLVED] try-empty-password= option in /etc/crypttab

You'd have to make another 0-byte file (`touch somenewfile`) or set --keyfile-offset to the filesize in bytes (so it actually reads 0 bytes from the file) but that's very counter-intuitive.

It’s unbelievable that there is no better way to achieve this, but you’re absolutely right! Two different methods seems to work equally well.

Method 1: Select an arbitrary filename of a non-existing file of your choice, for example key.tmp, touch it, use it, and then delete it.

$ touch /tmp/key.tmp
$ sudo cryptsetup open --key-file /tmp/key.tmp /test/volume.img myvolume
$ rm /tmp/key.tmp

Method 2: Select an arbitrary existing file, measure the size of that file in bytes, and use that file as a key file with the same number of bytes specified as offset:

$ sudo cryptsetup open --key-file /home/user/mydocument.odt --keyfile-offset $(stat -c %s /home/user/mydocument.odt) /test/volume.img myvolume

Thank you for your input. Case [SOLVED].