8000 Artix Linux: LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2 · Issue #3361 · rear/rear · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Artix Linux: LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2 #3361

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
castilma opened this issue Dec 11, 2024 · 3 comments
Open

Artix Linux: LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2 #3361

castilma opened this issue Dec 11, 2024 · 3 comments
Labels
enhancement Adaptions and new features
Milestone
ReaR 3.0

Comments

@castilma
Copy link
Contributor
castilma commented Dec 11, 2024 •
edited
Loading

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.7 / Git

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

NAME="Artix Linux"
PRETTY_NAME="Artix Linux"
ID=artix
BUILD_ID=rolling
ANSI_COLOR="0;36"
HOME_URL="https://www.artixlinux.org/"
DOCUMENTATION_URL="https://wiki.artixlinux.org/"
SUPPORT_URL="https://forum.artixlinux.org/"
BUG_REPORT_URL="https://bugs.artixlinux.org/"
PRIVACY_POLICY_URL="https://terms.artixlinux.org/docs/privacy-policy/"
LOGO=artixlinux-logo
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=RAWDISK
#OUTPUT_URL=

BACKUP=REQUESTRESTORE

REQUIRED_PROGS+=( restic )

KEYMAP="de-neo"
BOOTLOADER="GRUB2"

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    PC

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86_64

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI, GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    SSD

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):

NAME KNAME     PKNAME    TRAN   TYPE  FSTYPE LABEL   SIZE MOUNTPOINT
/dev/sda
|    /dev/sda            sata   disk               447,1G 
|-/dev/sda1
|    /dev/sda1 /dev/sda         part                 200M /efi
|-/dev/sda2
|    /dev/sda2 /dev/sda         part                   1M 
`-/dev/sda3
  |  /dev/sda3 /dev/sda         part               446,9G 
  `-/dev/mapper/lvmSystem
    |  /dev/dm-0 /dev/sda3        crypt              446,9G 
    |-/dev/mapper/lvmSystem-volSwap
    |  /dev/dm-1 /dev/dm-0        lvm                    8G [SWAP]
    `-/dev/mapper/lvmSystem-volRoot
       /dev/dm-2 /dev/dm-0        lvm                438,9G /
/dev/sr0
     /dev/sr0            sata   rom                  7,8G
  • Description of the issue (ideally so that others can reproduce it):

If a key-slot uses the key derivation function pbkdf2, luksDump outputs a Hash: line for that entry. This
breaks the 'hash' checking code in 260_crypt_layout.sh, because multiple Hash: lines exist and the test argument is not quoted:

rear/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh

Line 118 in 40cbaaf

if ! test $hash ; then

Like in line 87, the extraction should probably just choose one line, but not always the first one! Right now it accepts all lines:

rear/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh

Line 88 in 40cbaaf

hash=$( grep "Hash" $TMP_DIR/cryptsetup.luksDump | sed -r 's/^.+:\s*(.+)$/\1/' )

Reproduce like this:

$ head -c 10M /dev/zero >img.iso
$ cryptsetup luksFormat --type luks1 img.iso 
$ cryptsetup convert /tmp/img.iso  --type luks2
$ cryptsetup luksDump /tmp/img.iso 
LUKS header information
Version:       	2
Epoch:         	2
Metadata area: 	16384 [bytes]
Keyslots area: 	2064384 [bytes]
UUID:          	f100df28-dd7b-4fd4-890f-da0115a7e079
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 2097152 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      pbkdf2
	Hash:       sha256
	Iterations: 1222116
	Salt:       ae d6 86 ce 59 8d 45 a1 83 12 e6 1e 76 df ca 20 
	            a2 f7 0e cb f5 18 15 b0 fd bc d1 14 54 f3 5a a1 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 76293
	Salt:       d5 86 16 6c 54 2c 62 da 36 b4 82 31 84 67 9d f5 
	            6f 3c e5 a0 d3 82 33 32 54 bd d0 0d ec 89 ac b0 
	Digest:     75 7b b1 29 cd 6b 14 98 22 26 72 1c c4 ca a5 fd 
	            db 3e fd a3

Note the new 'Hash:' line in the first key slot. I believe rear is interested in the second one under Digests:.

Background: I upgraded my LUKS1 device to LUKS2 (after reading this PSA), but did not follow the last step to update the pbkdf to argon, which I is the default for luks2 devices. So I ended up having a keyslot with the 'pbkdf2', which should be pretty rare with luks2.

  • Workaround, if any:
    Update the keyslot by running $ cryptsetup luksConvertKey <DEVICE> --pbkdf argon2id with the corresponding password.
@castilma castilma changed the title LUKS2 hash is not correctly handled when the cry LUKS2 hash is not correctly handled when the cryptdevice was upgraded from LUKS1 Dec 11, 2024
@castilma castilma changed the title LUKS2 hash is not correctly handled when the cryptdevice was upgraded from LUKS1 LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2 Dec 11, 2024
@jsmeix jsmeix added the enhancement Adaptions and new features label Dec 11, 2024
@jsmeix
Copy link
Member
jsmeix commented Dec 11, 2024

@castilma
did you get some

"No 'hash' value for LUKS.. volume ..."

message on your terminal?
If at all you would have got such a message only
if you did run "rear mkbackup/mkrescue" in verbose mode.

As far as I see in its comments the current code in
layout/save/GNU/Linux/260_crypt_layout.sh
https://github.com/rear/rear/blob/master/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh
seems to work as intended

    79          # More than one keyslot may be defined - use key_size from the first slot.
    80          # Depending on the version the "cryptsetup luksDump" command outputs the key_size value
    81          # as a line like
    82          #         Key:        512 bits
    83          # and/or as a line like
    84          #         Cipher key: 512 bits
    85          # cf. https://github.com/rear/rear/pull/2504#issuecomment-718729198 and subsequent comments
    86          # so we grep for both lines but use only the first match from the first slot:
    87          key_size=$( grep -E -m 1 "Key:|Cipher key:" $TMP_DIR/cryptsetup.luksDump | sed -r 's/^.+:\s*(.+) bits$/\1/' )
    88          hash=$( grep "Hash" $TMP_DIR/cryptsetup.luksDump | sed -r 's/^.+:\s*(.+)$/\1/' )
...
   102      # Using plain test to ensure a value is a single non empty and non blank word
   103      # without quoting because test " " would return zero exit code
   104      # cf. "Beware of the emptiness" in https://github.com/rear/rear/wiki/Coding-Style
...
   118      if ! test $hash ; then

which does not mean that the current code
will work for all possible cases
so the current code may need to be enhanced
to error out if a mandatory condition is not fulfilled
or to even also work for more special cases like this one.

Perhaps in current code

   118      if ! test $hash ; then
   119          LogPrint "No 'hash' value for LUKS$version volume $target_name in $source_device"
   120      fi

LogPrint should be at least LogPrintError or even Error
but right now I don't know if a hash value is mandatory.

@jsmeix jsmeix added this to the ReaR 3.0 milestone Dec 11, 2024
@castilma
Copy link
Contributor Author

Yes, I got some of these
"No 'hash' value for LUKS.. volume ..." lines. (I think it was with -v passed.)

@jsmeix jsmeix changed the title LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2 Artix Linux: LUKS2 hash is not correctly recognized when the cryptdevice contains a key-slot with pbkdf2 Dec 12, 2024
@jsmeix jsmeix mentioned this issue Dec 12, 2024
Open
@github-actions GitHub Actions

This comment has been minimized.

Sign in to view
@jsmeix jsmeix removed the no-issue-activity label Feb 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Adaptions and new features
Projects
None yet
Milestone
ReaR 3.0
Development

No branches or pull requests
2 participants
@jsmeix @castilma
0