#2432 Issue `closed`: Recovery of LUKS version 1 results in LUKS version 2 on newer systems¶

Labels: enhancement, fixed / solved / done, minor bug

OliverO2 opened issue at 2020-06-22 13:52:¶

ReaR version: 2.6
OS version: Ubuntu 20.04 LTS (and other systems using cryptsetup ≥ 2.1.0)
Description of the issue (ideally so that others can reproduce it):

While ReaR is known to not support recovery of a device encrypted with LUKS version 2 (#2204), it should correctly recover a device encrypted with LUKS version 1. However, on Ubuntu 20.04, recovering a LUKS version 1 device makes ReaR create a LUKS version 2 container. This prevents ReaR from creating a rescue medium afterwards due to lack of support for LUKS version 2.

As documented on ArchWiki, cryptsetup changed its defaults starting with version 2.1.0. So on newer systems, --type luks1 must be passed as an additional option to cryptsetup luksFormat if it is undesirable to create a LUKS version 2 container.

jsmeix commented at 2020-06-22 14:21:¶

So in etc/rear/local.conf something like

LUKS_CRYPTSETUP_OPTIONS+=" --type luks1"

cf.
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L1650
should help as a workaround until we could make things working
automatically by default in ReaR.

I guess we cannot just add in default.conf --type luks1
to the current LUKS_CRYPTSETUP_OPTIONS because
I fear on older systems cryptsetupmay not support that
or we are lucky and --type luks1 is supported on all
systems that are currently officially supported by ReaR, cf.
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L2513

jsmeix commented at 2020-06-23 11:58:¶

On SLES11 man cryptsetup does not show a --type option
so on SLES11 using --type luks1 makes things likely fail
but SLES11 is no longer officially supported by ReaR, cf.
https://github.com/rear/rear/blob/master/doc/rear-release-notes.txt#L2524

On SLES12 man cryptsetup reads (excerpts):

BASIC COMMANDS
  The following are valid actions for all supported device types.

  open <device> <name> --type <device_type>
    Opens (creates a mapping with) <name> backed by device <device>.
    Device type can be plain, luks (default), luks1, luks2, loopaes or tcrypt.
...
OPTIONS
  --type <device-type>
    Specifies required device type, for more info
    read BASIC COMMANDS section.

so since SLES12 using --type luks or --type luks1 or --type luks2
should be supported.

But in the luks (default) in man cryptsetup
indicates that having --type luks1 in default.conf
may result something different than the default --type luks.

On the other hand I cannot find in man cryptsetup
what the difference between --type luks and --type luks1 would be
because man cryptsetup only describes in the 'LUKS EXTENSION'
section that "LUKS2 is a new version of header format" but nothing
about 'LUKS1' - only 'LUKS' is mentioned there.

So it seems --type luks and --type luks1 mean the same
(why the heck don't they explicitly tell about it?)
so that it seems we may use --type luks1 in default.conf
without causing regressions on systems that are
currently officially supported by ReaR?

jsmeix commented at 2020-06-23 12:02:¶

@rear/contributors
does one of you know more details about LUKS
in particular if and what the differences are
between --type luks and --type luks1?

jsmeix commented at 2020-06-23 12:07:¶

On https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
I found (excerpt):

Encryption options with dm-crypt

Cryptsetup supports different encryption operating modes to use with dm-crypt:

    --type luks for using the default LUKS format version (LUKS1 with cryptsetup < 2.1.0, LUKS2 with cryptsetup ≥ 2.1.0),
    --type luks1 for using LUKS1, the most common version of LUKS,
    --type luks2 for using LUKS2, the latest available version of LUKS that allows additional extensions,
    --type plain for using dm-crypt plain mode,
    --type loopaes for a loopaes legacy mode,
    --type tcrypt for a TrueCrypt compatibility mode.

Accordingly --type luks would be useless in practice
and --type luks1 is the only right thing to enforce LUKS1.

jsmeix commented at 2020-06-23 12:33:¶

Because --type luks1 in default.conf
"just works" for my SLES12 LUKS test system. cf.
"SLES 12 SP 5 with default LUKS encrypted LVM and btrfs structure" in
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6
I will do a pull request soon...

jsmeix commented at 2020-06-23 13:08:¶

@OliverO2
I would appreciate it if you could review
https://github.com/rear/rear/pull/2437
i.e. check whether or not that makes things
work right by default also in your case.

OliverO2 commented at 2020-06-24 16:16:¶

@jsmeix
Sure, I'll look at it. Will be sometime next week as I'm too far away from my lab environment this week. ;)

jsmeix commented at 2020-06-30 06:49:¶

With https://github.com/rear/rear/pull/2437 merged this issue is fixed.

With https://github.com/rear/rear/pull/2437 merged
the LUKS_CRYPTSETUP_OPTIONS defaults
are no longer compatible with SLES11 cryptsetup, cf
https://github.com/rear/rear/issues/2432#issuecomment-648099580
which means a SLES11 user whos uses LUKS must manually specify
in his etc/rear/local.conf appropriate LUKS_CRYPTSETUP_OPTIONS
e.g. what the default had been before, cf.
https://github.com/rear/rear/commit/8472a679f9477ab1eab91fdb387620ce50ddc785

LUKS_CRYPTSETUP_OPTIONS="--iter-time 2000 --use-random"

@OliverO2
thank you for the issue report and for testing the fix!

[Export of Github issue for rear/rear.]

#2432 Issue closed: Recovery of LUKS version 1 results in LUKS version 2 on newer systems¶