cryptsetup luksFormat fails with -s <keysize>

Status changed to 'Confirmed' because the bug affects multiple users.

I see a potentially similar issue, but the offending option is `-c aes-xts` in my case.

Successful command `cryptsetup -i 5000 -h PBKDF2-sha256 -h sha512 luksFormat --debug /dev/e/enc`:

# cryptsetup 1.6.1 processing "cryptsetup -i 5000 -h PBKDF2-sha256 -h sha512 luksFormat --debug /dev/e/enc"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.

WARNING!
========
This will overwrite data on /dev/e/enc irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/e/enc context.
# Trying to open and read device /dev/e/enc.
# Initialising device-mapper backend library.
# Timeout set to 0 miliseconds.
# Iteration time set to 5000 miliseconds.
# Interactive passphrase entry requested.
Enter passphrase:
Verify passphrase:
# Formatting device /dev/e/enc as type LUKS1.
# Crypto backend (gcrypt 1.5.3) initialized.
# Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
# Generating LUKS header version 1 using hash sha512, aes, xts-plain64, MK 32 bytes
# Crypto backend (gcrypt 1.5.3) initialized.
# KDF pbkdf2, hash sha512: 180291 iterations per second.
# Data offset 4096, UUID ecde023d-d4f1-4e98-977d-8547ce9570b8, digest iterations 110000
# Updating LUKS header of size 1024 on device /dev/e/enc
# Key length 32, device size 2048000 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/e/enc
# Key length 32, device size 2048000 sectors, header size 2050 sectors.
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Crypto backend (gcrypt 1.5.3) initialized.
# KDF pbkdf2, hash sha512: 180788 iterations per second.
# Key slot 0 use 441376 password iterations.
# Using hash sha512 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area.
# Calculated device size is 250 sectors (RW), offset 8.
# dm version OF [16384] (*1)
# dm versions OF [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.27.0.
# Device-mapper backend running with UDEV support enabled.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-4478
# Udev cookie 0xd4d7800 (semid 2228240) created
# Udev cookie 0xd4d7800 (semid 2228240) incremented to 1
# Udev cookie 0xd4d7800 (semid 2228240) incremented to 2
# Udev cookie 0xd4d7800 (semid 2228240) assigned to CREATE task(0) with flags DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES (0xe)
# dm create temporary-cryptsetup-4478 CRYPT-TEMP-temporary-cryptsetup-4478 OF [16384] (*1)
# dm reload temporary-cryptsetup-4478 OFW [16384] (*1)
# dm resume temporary-cryptsetup-4478 OFW [16384] (*1)
# temporary-cryptsetup-4478: Stacking NODE_ADD (252,6) 0:6 0660 [verify_udev]
# temporary-cryptsetup-4478: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4d7800 (semid 2228240) decremented to 1
# Udev cookie 0xd4d7800 (semid 2228240) waiting for zero
# Udev cookie 0xd4d7800 (semid 2228240) destroyed
# temporary-cryptsetup-4478: Processing NODE_ADD (252,6) 0:6 0660 [verify_udev]
# temporary-cryptsetup-4478: Processing NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-4478 (252:6): read ahead is 256
# temporary-cryptsetup-4478 (252:6): S...

I ran into this problem again today and found my old bug report. I downloaded the source code for cryptsetup-1.6.7, and built it manually.

Version 1.6.7 gives me a more informative error message.

$ sudo ./cryptsetup -y -s 128 luksFormat /dev/sdd1

WARNING!
========
This will overwrite data on /dev/sdd1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
Failed to setup dm-crypt key mapping for device /dev/sdd1.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
Key size in XTS mode must be 256 or 512 bits.

As I understand it, the key size is doubled, because XTS uses two. So 256 == AES-128 and 512 == AES-256. You probably want 256. As such, I don't think this bug is valid because AES-64 doesn't exist.