# correct luks passphrase not working

## robak

Hi folks,

for my data I use a luks1 encrypted raid5. After I encountered a drive failure (see https://forums.gentoo.org/viewtopic-t-1114614-highlight-luks.html), rebuilded the raid and reinstalled the system my passphrase is not working anymore. I hope it's just me using cryptsetup wrong to open the device. So any help is highly appreciated.

Thou I know the passphrase is correct, I bruteforced all possible passphrases that I COULD have used, just to be sure I didn't missspell something.

Here is some output:

cryptsetup:

```

[root@localhost]# cryptsetup luksDump /dev/mapper/vg-multimedia

LUKS header information for /dev/mapper/vg-multimedia

Version:        1

Cipher name:    aes

Cipher mode:    xts-plain64

Hash spec:      sha1

Payload offset: 4096

MK bits:        512

MK digest:      xx xx xx xx xx xx xx xx xx xx xx xx xx

MK salt:        xx xx xx xx xx xx xx xx xx xx xx xx xx 

                xx xx xx xx xx xx xx xx xx xx xx xx

MK iterations:  88000

UUID:          xxxxxxx-xxxxx-xxx-xxxxxxxxx

Key Slot 0: ENABLED

        Iterations:             349249

        Salt:                   xx xx xx xx xx xx xx xx

        Key material offset:    8

        AF stripes:             4000

Key Slot 1: DISABLED

Key Slot 2: DISABLED

Key Slot 3: DISABLED

Key Slot 4: DISABLED

Key Slot 5: DISABLED

Key Slot 6: DISABLED

Key Slot 7: DISABLED

```

```

[root@localhost]# dmsetup info vg-multimedia

Name:              vg-multimedia

State:             ACTIVE

Read Ahead:        4096

Tables present:    LIVE

Open count:        1

Event number:      0

Major, minor:      253, 0

Number of targets: 1

UUID: LVM-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

```

The RAID:

```

[root@localhost nurbs999]# mdadm -D /dev/md0

/dev/md0:

           Version : 1.2

     Creation Time : Sun Mar  8 23:23:29 2015

        Raid Level : raid5

        Array Size : 3906764800 (3725.78 GiB 4000.53 GB)

     Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)

      Raid Devices : 3

     Total Devices : 4

       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Thu Jun 11 12:14:21 2020

             State : active

    Active Devices : 3

   Working Devices : 4

    Failed Devices : 0

     Spare Devices : 1

            Layout : left-symmetric

        Chunk Size : 512K

Consistency Policy : bitmap

              Name : localhost.localdomain:0  (local to host localhost.localdomain)

              UUID : xxxxxxx:xxxxxxx:xxxxxxx:xxxxxxxx

            Events : 105561

    Number   Major   Minor   RaidDevice State

       0       8       33        0      active sync   /dev/sdc1

       5       8       17        1      active sync   /dev/sdb1

       3       8       49        2      active sync   /dev/sdd1

       4     253        0        -      spare   /dev/dm-0

```

Greetings

robak

----------

## pietinger

Do you have a backup from your luks header ?

----------

## robak

nope :/

btw: I try to open the volume via 

```
cryptsetup luksOpen /dev/mapper/vg-multimedia multimedia
```

----------

## pietinger

 *robak wrote:*   

> nope :/

 

I dont want to be the one bringing you bad news, but ...    :Sad: 

Maybe someone else has a sudden idea for that.

(this is why I dont like luks; you have to backup something extra; I prefer old pure dmcrypt solutions)

----------

## robak

Any explanation how/why a recovery and or reinstallation of linux could damage/change a luks passphrase.

Would cryptsetup realize a damaged key?

----------

## pietinger

 *robak wrote:*   

> Would cryptsetup realize a damaged key?

 

I am not a luks expert, but as far as I know, only the masterkey has a checksum, so I think luks cannot proof if a password is wrong (you need a checksum for proofing the integrity of a piece of data). I have two links (in german) for you, giving you more detailed answers:

https://linux-blog.anracom.com/2018/11/13/dm-crypt-luks-begriffe-funktionsweise-und-die-rolle-des-hash-verfahrens-i/

https://linux-blog.anracom.com/2018/11/15/dm-crypt-luks-begriffe-funktionsweise-und-die-rolle-des-hash-verfahrens-ii/

----------

## fturco

The following link may be helpful: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions

----------

## Hu

Since your location specifies Germany, I am going to guess that you might use a keyboard layout other than US English.  There have been problems over the years where someone with a non-US keyboard would enter their passphrase with their native layout, then the early boot logic would request the password while the keyboard was still set for US English - and the passphrase was not spelled the same between the two layouts.  For recovery purposes, you may want to write the password in your favorite text editor, where you can see what you write, then paste that into the luksOpen prompt, so that cryptsetup receives exactly the text you visually confirmed as correct.

----------

## Budoka

Threads like this scare the hell out of me and this one may explain the continuing issue I've had with a mirrored drive not recognizing a correct luks password BUT...

What is it we should be "backing up" to prevent this kind of thing from happening???

Thanks

----------

## pietinger

 *Budoka wrote:*   

> What is it we should be "backing up" to prevent this kind of thing from happening??

 

You create a backup of the luks header with:

```
cryptsetup luksHeaderBackup /dev/sdXY --header-backup-file luks_backup
```

More in: https://blog.sleeplessbeastie.eu/2019/01/09/how-to-backup-or-restore-luks-header/

----------

## robak

Thank you for all the hints!

I am aware of the keyboard layout and checked that, too.

Well yes, backing up the header and store it in your own local nextcloud/owncloud instance would be a solution. In the case that the drives are dying and the encryption gets broken you would still have the header on your clients.

----------

