[dm-crypt] cryptsetup bug

[dm-crypt] cryptsetup bug

[divyashree kumar]

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

Sir ,


        I am Priyadarshee  Divyashree Kumar from Odisha , India . I am in a
serious trouble . My brother is a Judicial Magistrate in the court and he is
provided with a HCL laptop from the court with preinstalled customized RHEL5
client . He just asked me to install some player so that he can listen some
musics or watch some videos . I just installed VLC,MPLAYER,XINE and MIRO ,
but while installing I used external repositories from rpmforge, pbone and
epel . All gone successfull .


     The laptop has 160 GB harddrive and among which 128 GB are LVM and is
LUKS encrypted which is his  home directory containing various legal
documents from courts and the cases and a lot . After some hours of ,when I
turn on the laptop , it gives an error as

     starting disc encryption , command failed : Error opening device ;no
> such file or directory ;
>
and it asks for entering the passphrase again and again 3 times even with
providing with correct passwords .

I just googled and try with a live CD , but no result , the result returned
a follows :

#cryptsetup -v luksDump /dev/mapper/homevg-homevol

LUKS header information for /dev/mapper/homevg-homevol
>
> Version: 1
> Cipher name: aes
> Cipher mode: cbc-essiv:sha256
> Hash spec: sha1
> Payload offset: 1032
> MK bits: 128
> MK digest: 2a 77 66 d8 24 23 36 b1 c3 91 6d 0d 9d 1e ff 19 3f fe 16 67
> MK salt: de 14 b0 ac 51 18 3c c0 97 77 40 31 38 07 fe f4
> 28 43 06 a9 a2 98 22 6c 67 fc af 71 fd 76 4d f9
> MK iterations: 10
> UUID: c0be1231-cf29-48ac-8cba-1bf98b180051
>
> Key Slot 0: ENABLED
> Iterations: 181173
> Salt: f7 4a 8b 83 5f d4 ed e2 7f 42 42 38 eb bc 46 d2
> fd b1 7c c5 83 f0 3e 34 83 0f ff 0f 32 95 54 17
> 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
>

And with looksOpen ,

# cryptsetup luksOpen /dev/mapper/homevg-homevol home
> Enter LUKS passphrase for /dev/mapper/homevg-homevol:
> Enter LUKS passphrase for /dev/mapper/homevg-homevol:
> Enter LUKS passphrase for /dev/mapper/homevg-homevol:
> Command failed: No key available with this passphrase.
>


I am trying since last 10-12 hrs wihout a single hope , but as it contains
last 5 months of courtwork , I am completely out of mind what to do ,how to
do , how to recover the home ?

I dont know if this is a bug or anything , but I have to return his laptop
as it was .


Kindly ,any help will be thankful .

Sincerely..
Priyadarshee Divyashree Kumar

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

Re: [dm-crypt] cryptsetup bug

[morphium]

2010/7/12 divyashree kumar <divyashree.kumar@gmail.com>:
> Sir ,
>
>
>         I am Priyadarshee  Divyashree Kumar from Odisha , India . I am in a
> serious trouble . My brother is a Judicial Magistrate in the court and he is

Until here, I thought that it is some Nigeria Scam ;)

Good luck with recovering the data!

morphium

Re: [dm-crypt] cryptsetup bug

[Arno Wagner]

Hi,

as far as I can tell, the header and keyslot look healthy.
Of course some overwritten bytes in the Key-slot would
not show, but they should not happen on the operations 
you describe.

Make very sure you are inputing the correct passphrase.
Maybe the keyborad-layout subtly changed? Did this same
passphrase work before for you, i.e. do you have a clear
good-before bad-after situation?

You can send me the complete header (if you want, but not
the data part please and not the passphrase) and I can have 
a look for obvious corruption. You find the information on
how to do a header backup in the FAQ: 

   http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

There may also be something wring with the LVM, e.g.
overlapping partitions or the like. This could have done 
arbitrary damage, but should be visible in the key-slot data.

Arno

On Mon, Jul 12, 2010 at 04:09:21AM +0530, divyashree kumar wrote:
> Sir ,
> 
> 
>         I am Priyadarshee  Divyashree Kumar from Odisha , India . I am in a
> serious trouble . My brother is a Judicial Magistrate in the court and he is
> provided with a HCL laptop from the court with preinstalled customized RHEL5
> client . He just asked me to install some player so that he can listen some
> musics or watch some videos . I just installed VLC,MPLAYER,XINE and MIRO ,
> but while installing I used external repositories from rpmforge, pbone and
> epel . All gone successfull .
> 
> 
>      The laptop has 160 GB harddrive and among which 128 GB are LVM and is
> LUKS encrypted which is his  home directory containing various legal
> documents from courts and the cases and a lot . After some hours of ,when I
> turn on the laptop , it gives an error as
> 
>      starting disc encryption , command failed : Error opening device ;no
> > such file or directory ;
> >
> and it asks for entering the passphrase again and again 3 times even with
> providing with correct passwords .
> 
> I just googled and try with a live CD , but no result , the result returned
> a follows :
> 
> #cryptsetup -v luksDump /dev/mapper/homevg-homevol
> 
> LUKS header information for /dev/mapper/homevg-homevol
> >
> > Version: 1
> > Cipher name: aes
> > Cipher mode: cbc-essiv:sha256
> > Hash spec: sha1
> > Payload offset: 1032
> > MK bits: 128
> > MK digest: 2a 77 66 d8 24 23 36 b1 c3 91 6d 0d 9d 1e ff 19 3f fe 16 67
> > MK salt: de 14 b0 ac 51 18 3c c0 97 77 40 31 38 07 fe f4
> > 28 43 06 a9 a2 98 22 6c 67 fc af 71 fd 76 4d f9
> > MK iterations: 10
> > UUID: c0be1231-cf29-48ac-8cba-1bf98b180051
> >
> > Key Slot 0: ENABLED
> > Iterations: 181173
> > Salt: f7 4a 8b 83 5f d4 ed e2 7f 42 42 38 eb bc 46 d2
> > fd b1 7c c5 83 f0 3e 34 83 0f ff 0f 32 95 54 17
> > 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
> >
> 
> And with looksOpen ,
> 
> # cryptsetup luksOpen /dev/mapper/homevg-homevol home
> > Enter LUKS passphrase for /dev/mapper/homevg-homevol:
> > Enter LUKS passphrase for /dev/mapper/homevg-homevol:
> > Enter LUKS passphrase for /dev/mapper/homevg-homevol:
> > Command failed: No key available with this passphrase.
> >
> 
> 
> I am trying since last 10-12 hrs wihout a single hope , but as it contains
> last 5 months of courtwork , I am completely out of mind what to do ,how to
> do , how to recover the home ?
> 
> I dont know if this is a bug or anything , but I have to return his laptop
> as it was .
> 
> 
> Kindly ,any help will be thankful .
> 
> Sincerely..
> Priyadarshee Divyashree Kumar

> _______________________________________________
> 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] Cryptsetup bug

[Hunter DeMeyer]

[-- Attachment #1.1: Type: text/plain, Size: 153 bytes --]

I believe that under certain circumstances cryptsetup will encrypt more
than one partion on a drive. I have attached the process that produced this
bug.

[-- Attachment #1.2: Type: text/html, Size: 273 bytes --]

[-- Attachment #2: cryptsetup_bug --]
[-- Type: application/octet-stream, Size: 3635 bytes --]

[root@arch mnt]# ls
boot  efi
[root@arch mnt]# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): n
Partition number (1-128, default 1): 
First sector (34-30662622, default = 2048) or {+-}size{KMGTP}: 
Last sector (2048-30662622, default = 30662622) or {+-}size{KMGTP}: +512M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): ef00
Changed type of partition to 'EFI System'

Command (? for help): n
Partition number (2-128, default 2): 
First sector (34-30662622, default = 1050624) or {+-}size{KMGTP}: 
Last sector (1050624-30662622, default = 30662622) or {+-}size{KMGTP}: +1024M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.
[root@arch mnt]# cryptsetup --debug --cipher serpent-cbc-essiv:sha256 --hash tiger2 luksFormat /dev/sdb2
# cryptsetup 1.7.3 processing "cryptsetup --debug --cipher serpent-cbc-essiv:sha256 --hash tiger2 luksFormat /dev/sdb2"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.

WARNING!
========
This will overwrite data on /dev/sdb2 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/sdb2 context.
# Trying to open and read device /dev/sdb2 with direct-io.
# Initialising device-mapper backend library.
# Timeout set to 0 miliseconds.
# Iteration time set to 2000 milliseconds.
# Interactive passphrase entry requested.
Enter passphrase: 
Verify passphrase: 
# Formatting device /dev/sdb2 as type LUKS1.
# Crypto backend (gcrypt 1.7.5) initialized in cryptsetup library version 1.7.3.
# Detected kernel Linux 4.8.13-1-ARCH x86_64.
# Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
# Checking if cipher serpent-cbc-essiv:sha256 is usable.
# Using userspace crypto wrapper to access keyslot area.
# Generating LUKS header version 1 using hash tiger2, serpent, cbc-essiv:sha256, MK 32 bytes
# KDF pbkdf2, hash tiger2: 942964 iterations per second (256-bits key).
# Data offset 4096, UUID 8f6b6ff5-2f49-4edf-a35b-0e8df82e1e44, digest iterations 230000
# Updating LUKS header of size 1024 on device /dev/sdb2
# Key length 32, device size 2097152 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/sdb2
# Key length 32, device size 2097152 sectors, header size 2050 sectors.
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# KDF pbkdf2, hash tiger2: 963764 iterations per second (256-bits key).
# Key slot 0 use 1882351 password iterations.
# Using hash tiger2 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area.
# Using userspace crypto wrapper to access keyslot area.
# Key slot 0 was enabled in LUKS header.
# Updating LUKS header of size 1024 on device /dev/sdb2
# Key length 32, device size 2097152 sectors, header size 2050 sectors.
# Reading LUKS header of size 1024 from device /dev/sdb2
# Key length 32, device size 2097152 sectors, header size 2050 sectors.
# Releasing crypt device /dev/sdb2 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.
[root@arch mnt]# mount /dev/sdb1 efi
mount: unknown filesystem type 'crypto_LUKS'

Re: [dm-crypt] Cryptsetup bug

[Michael Kjörling]

On 29 Dec 2016 12:53 -0500, from hd4pix@gmail.com (Hunter DeMeyer):
> I believe that under certain circumstances cryptsetup will encrypt more
> than one partion on a drive. I have attached the process that produced this
> bug.

I suspect that a full strace output from the cryptsetup run would be
useful in attempting to track this down.

However, the first thing that strikes me is that your log does not
show conclusively that the kernel is working with current data,
particularly partition offsets data.

I can see no reason why cryptsetup would be working with any device
other than the one named.

Assuming udev (otherwise adjust as appropriate), a udev device re-scan
between creating the partitions and luksFormat would be a good first
step. Also confirm that doing so refreshes the partition device nodes,
for example by first wiping all partitioning information and showing
conclusively that no partitions are found by the kernel (for example
by `hdparm -z` and showing us the relevant `dmesg` output and /dev
contents), then partitioning and showing conclusively that the newly
created partitions are found and reflected in the device nodes.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] Cryptsetup bug

[Arno Wagner]

Please do not post HTML-Email here and please include
logs in the message itself.

Regards,
Arno



On Thu, Dec 29, 2016 at 18:53:57 CET, Hunter DeMeyer wrote:
>    I believe that under certain circumstances cryptsetup will encrypt more
>    than one partion on a drive. I have attached the process that produced
>    this bug.


> _______________________________________________
> 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] Cryptsetup bug

[Milan Broz]

On 12/29/2016 06:53 PM, Hunter DeMeyer wrote:
> I believe that under certain circumstances cryptsetup will encrypt
> more than one partion on a drive. I have attached the process that
> produced this bug.

Cryptsetup accesses only device that you specify.

There are two options how could happen that LUKS device appeared on different partition:

1) there was some old LUKS device on the /dev/sdb1 offset start already or
2) you recreated partitions but for some reason kernel still see the old partitions size,
and sdb1 was still in fact mapped to the old partition.

Could you please paste blkid /dev/sdb* to verify it is the first option (to check LUKS UUID)?
I guess you will see different UUIDs.

And please do not send html mails to the list.

Milan

Re: [dm-crypt] Cryptsetup bug

[Hunter DeMeyer]

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

/dev/sdb1: UUID="fc1abc36-a8f8-4ace-b324-77f9ddd037ea" TYPE="crypto_LUKS"
PARTLABEL="EFI System" PARTUUID="bacaef0b-61a8-4460-98e7-8a2251d78268"

/dev/sdb2: UUID="8f6b6ff5-2f49-4edf-a35b-0e8df82e1e44" TYPE="crypto_LUKS"
PARTLABEL="Linux filesystem" PARTUUID="a58cce87-f792-4e5b-8c35-b4210472f86c"


On Thu, Dec 29, 2016 at 9:18 PM, Milan Broz <gmazyland@gmail.com> wrote:

> On 12/29/2016 06:53 PM, Hunter DeMeyer wrote:
> > I believe that under certain circumstances cryptsetup will encrypt
> > more than one partion on a drive. I have attached the process that
> > produced this bug.
>
> Cryptsetup accesses only device that you specify.
>
> There are two options how could happen that LUKS device appeared on
> different partition:
>
> 1) there was some old LUKS device on the /dev/sdb1 offset start already or
> 2) you recreated partitions but for some reason kernel still see the old
> partitions size,
> and sdb1 was still in fact mapped to the old partition.
>
> Could you please paste blkid /dev/sdb* to verify it is the first option
> (to check LUKS UUID)?
> I guess you will see different UUIDs.
>
> And please do not send html mails to the list.
>
> Milan
>

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

Re: [dm-crypt] Cryptsetup bug

[Sven Eschenberg]

Since sdb1 has a UUID that differes from the one that was just created 
it seems to be a stale one.

If you want to verify what's going on and you are sure you can reproduce 
it by the same steps then do the following:

Create your partitions, then verify there's no stale signatures.
First verify the kernel reflects your partitioning on the disk.
Then run blkid.
If there's signatures, use something like wipefs to remove them (or dd 
zeros).
Then recreate the container on sdb2 by issuing your appropriate command.
And run blkid again, to verify only on sdb2 a signature was created.

If suddendly a new luks signature would pop up on sdb1, you can start 
stracing the problem.

Regards

-Sven


Am 30.12.2016 um 03:46 schrieb Hunter DeMeyer:
> /dev/sdb1: UUID="fc1abc36-a8f8-4ace-b324-77f9ddd037ea"
> TYPE="crypto_LUKS" PARTLABEL="EFI System"
> PARTUUID="bacaef0b-61a8-4460-98e7-8a2251d78268"
>
> /dev/sdb2: UUID="8f6b6ff5-2f49-4edf-a35b-0e8df82e1e44"
> TYPE="crypto_LUKS" PARTLABEL="Linux filesystem"
> PARTUUID="a58cce87-f792-4e5b-8c35-b4210472f86c"
>
>
> On Thu, Dec 29, 2016 at 9:18 PM, Milan Broz <gmazyland@gmail.com
> <mailto:gmazyland@gmail.com>> wrote:
>
>     On 12/29/2016 06:53 PM, Hunter DeMeyer wrote:
>     > I believe that under certain circumstances cryptsetup will encrypt
>     > more than one partion on a drive. I have attached the process that
>     > produced this bug.
>
>     Cryptsetup accesses only device that you specify.
>
>     There are two options how could happen that LUKS device appeared on
>     different partition:
>
>     1) there was some old LUKS device on the /dev/sdb1 offset start
>     already or
>     2) you recreated partitions but for some reason kernel still see the
>     old partitions size,
>     and sdb1 was still in fact mapped to the old partition.
>
>     Could you please paste blkid /dev/sdb* to verify it is the first
>     option (to check LUKS UUID)?
>     I guess you will see different UUIDs.
>
>     And please do not send html mails to the list.
>
>     Milan
>
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>