[Bug 1843181] [NEW] cryptsetup-reencrypt may use an incorrect hash if the hash parameter is omitted

[Matthias Kruzenski]

Public bug reported:

Let's say:

- someone setup a fully encrypted bootable ubuntu system
- the /boot directory resists in the encrypted root filesystem so that it is also encrypted
- the parameters --cipher=aes-xts-plain64 and --hash=sha512 have been passed to cryptsetup luksFormat
- everything was configured correctly so that GRUB is able to boot the encrypted system
- everything works fine, when you turn on the computer you will be prompted to unlock the encrypted system


Let's get to the problem:

- for some reason someone want to re-encrypt the entire system which is easily possible with cryptsetup-reencrypt
- this is done with the following command: cryptsetup-reencrypt /dev/sda3 --key-file=secret.key --key-slot 0
- the re-encryption process is successful
- but the system is now no longer bootable because cryptsetup-reencrypt has used sha256 as hash and NOT sha512 which was used before


The reason why the system is unbootable is:

- the "early grub core image" which was created by grub-install does not
contain an sha256 module, and because of that grub is no longer able to
read the encrypted volume in stage 1

Conclusion:

- if no cipher and/or hash was passed to cryptsetup-reencrypt then
cryptsetup-reencrypt should take over the previous values of the
encrypted volume and not use the default hash value which is sha256,
only then the system will still be bootable


Note:

- I can confirm that the system is still bootable if the parameters
--cipher=aes-xts-plain64 and --hash=sha512 are passed to cryptsetup-
reencrypt explicitly


I know:

- grub-install could solve the issue but I think this is not the best
solution and the behavior described here should be considered as a bug.
A user expects everything to work without problems, and that everything
is same like before (same cipher, same hash).


Summery:

cryptsetup-reencrypt should simply re-encrypt, it should not make any
decisions regarding the hash or cipher since the consequences are not
foreseeable.

** Affects: cryptsetup (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: cryptsetup-reencrypt hash sha256 sha512

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1843181

Title:
  cryptsetup-reencrypt may use an incorrect hash if the hash parameter
  is omitted

Status in cryptsetup package in Ubuntu:
  New

Bug description:
  Let's say:

  - someone setup a fully encrypted bootable ubuntu system
  - the /boot directory resists in the encrypted root filesystem so that it is also encrypted
  - the parameters --cipher=aes-xts-plain64 and --hash=sha512 have been passed to cryptsetup luksFormat
  - everything was configured correctly so that GRUB is able to boot the encrypted system
  - everything works fine, when you turn on the computer you will be prompted to unlock the encrypted system

  
  Let's get to the problem:

  - for some reason someone want to re-encrypt the entire system which is easily possible with cryptsetup-reencrypt
  - this is done with the following command: cryptsetup-reencrypt /dev/sda3 --key-file=secret.key --key-slot 0
  - the re-encryption process is successful
  - but the system is now no longer bootable because cryptsetup-reencrypt has used sha256 as hash and NOT sha512 which was used before

  
  The reason why the system is unbootable is:

  - the "early grub core image" which was created by grub-install does
  not contain an sha256 module, and because of that grub is no longer
  able to read the encrypted volume in stage 1

  Conclusion:

  - if no cipher and/or hash was passed to cryptsetup-reencrypt then
  cryptsetup-reencrypt should take over the previous values of the
  encrypted volume and not use the default hash value which is sha256,
  only then the system will still be bootable

  
  Note:

  - I can confirm that the system is still bootable if the parameters
  --cipher=aes-xts-plain64 and --hash=sha512 are passed to cryptsetup-
  reencrypt explicitly

  
  I know:

  - grub-install could solve the issue but I think this is not the best
  solution and the behavior described here should be considered as a
  bug. A user expects everything to work without problems, and that
  everything is same like before (same cipher, same hash).

  
  Summery:

  cryptsetup-reencrypt should simply re-encrypt, it should not make any
  decisions regarding the hash or cipher since the consequences are not
  foreseeable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1843181/+subscriptions