[dm-crypt] LUKS keyslot 4 is invalid.

[dm-crypt] LUKS keyslot 4 is invalid.

[Mika Kujanpää]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

I've tried to find information, if there is some possibility to recover 
access to disk. When I try luksOpen or luksDump, i get

cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3
LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.

or

cryptsetup luksOpen 
/dev/disk/by-uuid/96914f6d-25c8-43d2-8133-2d9c971db9df vara
LUKS keyslot 4 is invalid.
LUKS keyslot 5 is invalid.

[-- Attachment #2: Type: text/html, Size: 781 bytes --]

Re: [dm-crypt] LUKS keyslot 4 is invalid.

[Milan Broz]

On 11/26/2011 03:19 PM, Mika Kujanpää wrote:
> I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get
> 
> cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3
> LUKS keyslot 4 is invalid.
> LUKS keyslot 5 is invalid.

Which cryptsetup version?

Basically it means that either kesylot has wrong offset
(or there is bug in cryptsetup itself, I recently added
some offset check code here).

Could you send me (to private mail, not to list) dd of this
broken LUKS header so I can check what's wrong?

(just first 4k of device - without private keyslots area,
e.g. only visible information - you can use this command

dd if=<luks_device> of=<backup_file> bs=4096 count=1

Thanks,
Milan

Re: [dm-crypt] LUKS keyslot 4 is invalid.

[Milan Broz]

On 11/26/2011 07:45 PM, Milan Broz wrote:
> On 11/26/2011 03:19 PM, Mika Kujanpää wrote:
>> I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get
>>
>> cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3
>> LUKS keyslot 4 is invalid.
>> LUKS keyslot 5 is invalid.

Perhaps another item to FAQ:

In cryptsetup 1.4.x I added check of keyslot data offset.
(Keyslot offset is calculated during format for all slots
including inactive slots.)

If any keyslot offset points to the area outside of LUKS header,
header is corrupted (IOW keylot point to the payload data area
and in theory can overwrite user data when activated.)

And exactly this happened there, inactive slot 4 and 5 had
wrong offset. Because there was know signature 0x55 0xAA in last
bytes of the first sector I guess some "clever" partition tool
wrote few bytes there after LUKS was formatted.

if you run luksDump --debug here, you will see better error
message, here e.g.

# Reading LUKS header of size 1024 from device /dev/sdb
# Invalid offset 1760061416 in keyslot 4 (beyond data area offset 4096).
LUKS keyslot 4 is invalid.


How to fix that depends on situation...

If you have old cryptsetup, you can activate device and reformat
the header using "How do I recover the master key
from a mapped LUKS container?" in FAQ.

With exact knowledge of LUKS header you can fix that manually.
(I used simple dd from another device in this case but offset depends
on situation.)

Milan

Re: [dm-crypt] LUKS keyslot 4 is invalid.

[Arno Wagner]

Hi Lilan,

I will add this. The check is a pretty good idea IMO.

Arno

On Sun, Nov 27, 2011 at 12:33:08PM +0100, Milan Broz wrote:
> On 11/26/2011 07:45 PM, Milan Broz wrote:
> > On 11/26/2011 03:19 PM, Mika Kujanp?? wrote:
> >> I've tried to find information, if there is some possibility to recover access to disk. When I try luksOpen or luksDump, i get
> >>
> >> cryptsetup luksDump /dev/disk/by-uuid/7fa45e9b-6b3d-4ac7-becc-7b8fe5d463a3
> >> LUKS keyslot 4 is invalid.
> >> LUKS keyslot 5 is invalid.
> 
> Perhaps another item to FAQ:
> 
> In cryptsetup 1.4.x I added check of keyslot data offset.
> (Keyslot offset is calculated during format for all slots
> including inactive slots.)
> 
> If any keyslot offset points to the area outside of LUKS header,
> header is corrupted (IOW keylot point to the payload data area
> and in theory can overwrite user data when activated.)
> 
> And exactly this happened there, inactive slot 4 and 5 had
> wrong offset. Because there was know signature 0x55 0xAA in last
> bytes of the first sector I guess some "clever" partition tool
> wrote few bytes there after LUKS was formatted.
> 
> if you run luksDump --debug here, you will see better error
> message, here e.g.
> 
> # Reading LUKS header of size 1024 from device /dev/sdb
> # Invalid offset 1760061416 in keyslot 4 (beyond data area offset 4096).
> LUKS keyslot 4 is invalid.
> 
> 
> How to fix that depends on situation...
> 
> If you have old cryptsetup, you can activate device and reformat
> the header using "How do I recover the master key
> from a mapped LUKS container?" in FAQ.
> 
> With exact knowledge of LUKS header you can fix that manually.
> (I used simple dd from another device in this case but offset depends
> on situation.)
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

[dm-crypt] LUKS keyslot 4 is invalid

[Jarosław K]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Hi all,

I have an encrypted RAID 1 volume for /home directory. I set it to mount
automatically after login (based on
http://nanonanonano.net/linux/debian/enchome). All of it works perfect
during a few months. Until today ... After login I saw a "clean" user
profile on my Debian. I know that, my encrypted drive didn't mount
correctly. Unfortunately, manually mount failed too:

root@s4per-debian:/home/s4per# cryptsetup luksOpen
/dev/mapper/isw_echheajchc_Mirror crypt
Numer klucza LUKS 4 jest nieprawidłowy.   ---> LUKS keyslot 4 is invalid (?)

I have read something about this issue, and now i think it could be problem
with LUKS headers. But unfortunatelly i have no any backup of it.

In Poland we says "Polish wise after the event". Now I know, that I should
make some backup of headers.

I kindly request for some help.

My OS: Debian Sid AMD64

Regards,

s4per

[-- Attachment #2: Type: text/html, Size: 1057 bytes --]

Re: [dm-crypt] LUKS keyslot 4 is invalid

[Arno Wagner]

Hi s4per,

this should be caused by something wrinign over the info for
Keyslot 4 (and possibly later) in the header. 

First, before you do anything, make that header backup, as described
in the FAQ, Itmm 6.2.  It will prevent things from getting worse. 
(http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions)

Usually, you key should be in keyslot 1 and that may still be 
intact. As you can see in FAQ Item 6.12, keyslot infor for 
keyslot 4 is stored at offset 0x190, so anything damaging it 
could also have damaged other fields in the LUKS header.
Still, give this a try:

   cryptsetup repair <device>

It may work, or it may give you another error. If so, please
post that here. (Do NOT do this wiothout header backup!)

Arno





On Wed, Nov 19, 2014 at 23:52:38 CET, Jarosław K wrote:
> Hi all,
> 
> I have an encrypted RAID 1 volume for /home directory. I set it to mount
> automatically after login (based on
> http://nanonanonano.net/linux/debian/enchome). All of it works perfect
> during a few months. Until today ... After login I saw a "clean" user
> profile on my Debian. I know that, my encrypted drive didn't mount
> correctly. Unfortunately, manually mount failed too:
> 
> root@s4per-debian:/home/s4per# cryptsetup luksOpen
> /dev/mapper/isw_echheajchc_Mirror crypt
> Numer klucza LUKS 4 jest nieprawidłowy.   ---> LUKS keyslot 4 is invalid (?)
> 
> I have read something about this issue, and now i think it could be problem
> with LUKS headers. But unfortunatelly i have no any backup of it.
> 
> In Poland we says "Polish wise after the event". Now I know, that I should
> make some backup of headers.
> 
> I kindly request for some help.
> 
> My OS: Debian Sid AMD64
> 
> Regards,
> 
> s4per

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS keyslot 4 is invalid

[Jarosław K]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

*Hi Arno,Thanks for response.Unfortunatelly:root@s4per-debian:/home/s4per#
cryptsetup luksHeaderBackup --header-backup-file luksbackup
/dev/mapper/isw_echheajchc_MirrorNumer klucza LUKS 4 jest nieprawidłowy.*
---> LUKS keyslot 4 is invalid

Regards,

s4per

2014-11-19 23:52 GMT+01:00 Jarosław K <s4per89@gmail.com>:

> Hi all,
>
> I have an encrypted RAID 1 volume for /home directory. I set it to mount
> automatically after login (based on
> http://nanonanonano.net/linux/debian/enchome). All of it works perfect
> during a few months. Until today ... After login I saw a "clean" user
> profile on my Debian. I know that, my encrypted drive didn't mount
> correctly. Unfortunately, manually mount failed too:
>
> root@s4per-debian:/home/s4per# cryptsetup luksOpen
> /dev/mapper/isw_echheajchc_Mirror crypt
> Numer klucza LUKS 4 jest nieprawidłowy.   ---> LUKS keyslot 4 is invalid
> (?)
>
> I have read something about this issue, and now i think it could be
> problem with LUKS headers. But unfortunatelly i have no any backup of it.
>
> In Poland we says "Polish wise after the event". Now I know, that I should
> make some backup of headers.
>
> I kindly request for some help.
>
> My OS: Debian Sid AMD64
>
> Regards,
>
> s4per
>
>
>


-- 
Pozdrawiam,

Jarosław Kołata

[-- Attachment #2: Type: text/html, Size: 1961 bytes --]

Re: [dm-crypt] LUKS keyslot 4 is invalid

[Arno Wagner]

Then do it manually.

1. Look up the header size. It should be either 1'052'672 Bytes or 2MiB.
   What you need is the key-size.
      cryptsetup luksDump <device> 
   gives 
      ...
      MK bits:        256
      ...
   for 1'052'672 Bytes or the same with 512 for 2MiB.
   If that does nto work, and you do not know the size of your mater 
   key, dump 2MiB. Note: Do not change the filesystem if you
   want to restor a header that may be too large! With that,
   resyoting up to 1MiB of the filesystem is still safe.

2. Copy it manually. There are a nu,ber of options to do this, I
   prefer
      head -c 1052672 <device>  >  header_backup.dmp
   or
      head -c 2M <device>  >  header_backup.dmp
   for a 2MiB header.
   Verify the size of the file to be sure.

Keep that file safe, and you can try
 
   cryptsetup repair <device> 

next. 


I also just added this procedure to FAQ Item 6.2.


Gr"usse,
Arno

    
   

On Tue, Nov 25, 2014 at 22:50:57 CET, Jarosław K wrote:
> *Hi Arno,Thanks for response.Unfortunatelly:root@s4per-debian:/home/s4per#
> cryptsetup luksHeaderBackup --header-backup-file luksbackup
> /dev/mapper/isw_echheajchc_MirrorNumer klucza LUKS 4 jest nieprawidłowy.*
> ---> LUKS keyslot 4 is invalid
> 
> Regards,
> 
> s4per
> 
> 2014-11-19 23:52 GMT+01:00 Jarosław K <s4per89@gmail.com>:
> 
> > Hi all,
> >
> > I have an encrypted RAID 1 volume for /home directory. I set it to mount
> > automatically after login (based on
> > http://nanonanonano.net/linux/debian/enchome). All of it works perfect
> > during a few months. Until today ... After login I saw a "clean" user
> > profile on my Debian. I know that, my encrypted drive didn't mount
> > correctly. Unfortunately, manually mount failed too:
> >
> > root@s4per-debian:/home/s4per# cryptsetup luksOpen
> > /dev/mapper/isw_echheajchc_Mirror crypt
> > Numer klucza LUKS 4 jest nieprawidłowy.   ---> LUKS keyslot 4 is invalid
> > (?)
> >
> > I have read something about this issue, and now i think it could be
> > problem with LUKS headers. But unfortunatelly i have no any backup of it.
> >
> > In Poland we says "Polish wise after the event". Now I know, that I should
> > make some backup of headers.
> >
> > I kindly request for some help.
> >
> > My OS: Debian Sid AMD64
> >
> > Regards,
> >
> > s4per
> >
> >
> >
> 
> 
> -- 
> Pozdrawiam,
> 
> Jarosław Kołata

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS keyslot 4 is invalid

[Jarosław K]

Hi Arno,

Thanks for help!

After repair everything is alright.
I made header backup, and I put it in few different places.
Now I can sleep safely.

Again thanks a lot!

Regards,
s4per

Re: [dm-crypt] LUKS keyslot 4 is invalid

[Arno Wagner]

Hi s4per,

you are welcome. Good to know it worked!

Gr"usse,
Arno

On Wed, Nov 26, 2014 at 18:11:16 CET, Jarosław K wrote:
> Hi Arno,
> 
> Thanks for help!
> 
> After repair everything is alright.
> I made header backup, and I put it in few different places.
> Now I can sleep safely.
> 
> Again thanks a lot!
> 
> Regards,
> s4per
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier