cryptsetup luksFormat fails with -s <keysize>

Bug #1299557 reported by mpb
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I installed beta2 of 14.04 yesterday. Today, I am trying to manually create an encrypted partition. If I specify a key size to cryptsetup with -s, cryptsetup fails as follows.

root@slab:~# cryptsetup -y -s 128 luksFormat /dev/sda6
WARNING!
========
This will overwrite data on /dev/sda6 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
device-mapper: reload ioctl on failed: Invalid argument
Failed to open temporary keystore device.
device-mapper: remove ioctl on temporary-cryptsetup-2231 failed: No such device or address
device-mapper: reload ioctl on temporary-cryptsetup-2231 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-2231 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-2231 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-2231 failed: No such device or address
device-mapper: remove ioctl on temporary-cryptsetup-2231 failed: No such device or address

After the above, luksDump shows all 8 key slots as DISABLED.

Without -s, cryptsetup will succeed, as follows.

root@slab:~# cryptsetup -y luksFormat /dev/sda6
WARNING!
========
This will overwrite data on /dev/sda6 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase:
Verify passphrase:
root@slab:~#

Other info:

root@slab:~# lsb_release -rd
Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04

root@slab:~# apt-cache policy cryptsetup
cryptsetup:
  Installed: 2:1.6.1-1ubuntu1
  Candidate: 2:1.6.1-1ubuntu1
  Version table:
 *** 2:1.6.1-1ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Revision history for this message
bJXjLjEHIaWT0tFd (bjxjljehiawt0tfd-deactivatedaccount) wrote :
Download full text (11.0 KiB)

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...

Revision history for this message
mpb (mpb) wrote :

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.

Revision history for this message
GreenReaper (greenreaper) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.