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

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.