Debian Question posted in
The oficial documentation can be found here.

Receiving "No key available with this passphrase" with LUKS – Debian

My laptop has an encrypted disk. After an apt upgrade and some hours later a force shutdown my passphrase doesn’t decrypt my disk anymore.

I booted from a debian live usb stick and tried several things:

  1. Can I decrypt the partition with my passphrase from the live os?
    enter image description here
    Answer: No.
  2. Is it a problem with the keyboard layout?
    enter image description here
    Answer: No.
  3. Is the partition still an encrypted one?
    enter image description here
    Answer: Yes it is and there is still one keyslot.
  4. Is there a problem visible when looking at hexdump output?
    enter image description here
    Answer: No.
  5. Is there maybe a problem visibile when looking at the hexdump configuration output?
    enter image description here
    Answer: Apart from the fact that a few blog posts say that everything above 1000 should be random characters: No.

I have no backup of my LUKS headers. My passphrase worked for over one year. How can I access or rescue my data?

Thanks in advance,
Luke

Tags:

3

Answers


  1. 0

    Maybe too much time is gone by since you ask your question but:

    After an apt upgrade and some hours later a force shutdown my passphrase doesn’t decrypt my disk anymore.

    This shouldn’t be a problem. I had to do that a lot on different devices. Yes, there is still a small possibility that this could damage something but LUKS is very robust.

    1. Can I decrypt the partition with my passphrase from the live os?

    Yes, that is definitely possible! Done it myself several times.

    1. Is it a problem with the keyboard layout?

    Possible. Write your passphrase in the terminal window to check if it is your password and then use the cryptsetup command. And rethink the possibility that you encrypted your drive with another layout. Try to remember how you encrypted it – during a fresh system install; on your working system over the terminal; with a tool; etc. .

    PASSPHRASE CHARACTER SET: Some people have had difficulties with this
    when upgrading distributions. It is highly advisable to only use the 95
    printable characters from the first 128 characters of the ASCII table,
    as they will always have the same binary representation. Other
    characters may have different encoding depending on system configuration
    and your passphrase will not work with a different encoding.

    This quote is from Gitlab cryptsetup.

    1. Is the partition still an encrypted one?

    Yes it is. Make sure you use an up to date live cd with luks version2.

    I have no backup of my LUKS headers.

    Doesn’t look like you need a backup of the LUKS header.

    EDIT: Some additional ideas:
    How did you do the encryption? Is it a special partition like /home?

    • If the partition is your /home and you did the encryption setup
      during the system install then you normally open your partition by
      your user password. But that is not the real passphrase for that
      partition because there will be a keyfile for opening your partition.
      That file is defined in /etc/crypttab.
    • If you will be able to open your partition or setup a new one please make sure you
      • Setup not only one passphrase! Add another passphrase or a key-file in another keyslot.

    If you are sure you are entering the passphrase right, there is the
    possibility that the respective key-slot has been damaged. There is no
    way to recover a damaged key-slot, except from a header backup…

    This quote is also from Gitlab cryptsetup. Maybe you find more needed infos there.

    • After the passphrases are done DO A HEADER-BACKUP! It’s easy. The backup is small and most of the time you won’t need it – I did not for the last 10 years and so many harddiks, usb-sticks, etc.!
      • Do NOT store the header-backup in your encrypted harddisk/partition!
    Login or Signup to reply.
  2. 0

    You can try to create a new master key for your luks container

    ## Requires vim-common

cryptsetup luksAddKey /dev/sda3 --master-key-file <(dmsetup table --showkey /dev/mapper/foobar | awk '{print$5}' | xxd -r -p)

    This will create a new passphrase for unlocking luks container and if this works then you can remove the previous passphrase and continue using it.

    Login or Signup to reply.
  3. 0

    Most likely you’ve mistyped your password, as I had similar issue and blamed upgrade as well.

    You can dump the header and try to brutal force it.

    Following steps can help.

    1. Confirm you’ve the right device:

      sudo cryptsetup isLuks /dev/sda3 -v

    2. Validate the header:

      sudo cryptsetup luksDump /dev/sda3

    3. Try initial few passwords (consider adding --debug for more output):

      sudo cryptsetup luksOpen --test-passphrase /dev/sda3

      Or: tcryptDump, but shouldn’t make any difference.

    4. Consider to backup the header:

      sudo cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file luksHeader.bin

      Alternatively run (replace count with Payload offset found in header dump):

       dd if=/dev/sda3 of=luksHeader.bin bs=512 count=4096

      You can also consider to backup the whole device using dd.

    5. Use header file to try different passwords: (quicker than using the actual device)

      sudo cryptsetup luksOpen --test-passphrase luksHeader.bin

    Brutal force

    Having a small header file (as per above steps), you can try to brutal force it.

    Assuming you know your original password, create the list of your potential password and their permutations in passes.txt (make the list unique by sort -ou passes.txt).

    In shell, you can use the following script to try these combinations:

    set -x
while read pass; do
  printf $pass | cryptsetup luksOpen --test-passphrase luksHeader.bin $@ && echo Success && break;
done < passes.txt

    Notes:

    • Since the files are small, you can scale it to many machines.
    • Consider adding --key-slot 0 for quicker checks.
    • You can try to override --pbkdf-force-iterations (check how many there are in the header dump), but most likely it won’t help.

    Live CD

    If you think that happened due to upgrade, use different Ubuntu Live CDs to use the above commands (Ubuntu 16, 18, 20 and so on).

    Either boot from USB/CD, or install VM VirtualBox (Create Ubuntu VM, then load the ISO to boot from it).

    To attach the physical device to VM VirtualBox (not recommended):

    • In your newly created Ubuntu VM, attach Ubuntu’s Live CD .iso file.
    • Use VBoxManage internalcommands createrawvmdk command to create .vmdk files pointing to the real device. Attach these .vmdk into the VM (before starting it).
    • If your user won’t have access to these special devices during run, run VirtualBoxVM as root (also not recommended).

    Final steps, copy the header file then test passphrases using older version of cryptsetup (cryptsetup --version).

    Mounting

    Once success, use these commands to mount the filesystem:

    sudo cryptsetup isLuks /dev/sdb5 -v
sudo cryptsetup luksOpen /dev/sdb5 newhd
sudo lvscan # Check if LVs are active.
sudo vgchange -ay # Activate LVs if not active.
sudo lvdisplay # List logical volumes (note the LV Path).
sudo mount /dev/ubuntu-vg/root /mnt
mount # List mounted filesystems.
xdg-open /mnt # Open in file explorer

    Other useful commands:

    sudo lvmdiskscan # List devices.
sudo vgdisplay # Display volume group information.
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search