[dm-crypt] help

[dm-crypt] help

[Felix Wagner]

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

Hello,

I tried to reencrypt my device today and was way too eager to do it
without reading everything. Heres what I did:

'cryptsetup-reencrypt -v -c aes-xts-plain64 -s
512 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
Reencryption will change: volume key, set cipher to aes-xts-plain64.
Enter passphrase for key slot 0:
Key slot 0 unlocked.
LUKS header backup of
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 created.
Data offset for detached LUKS header must be either 0 or higher than
header size (4036 sectors). Creation of LUKS backup headers failed.

So i thought well It didn't work so lets try again:

cryptsetup-reencrypt -v -c
aes-xts-plain64 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
Reencryption will change: volume key, set cipher to aes-xts-plain64.
Enter passphrase for key slot 0:
Key slot 0 unlocked.
LUKS header
backup of device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
created.
New LUKS header for
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 created.
Activated keyslot 0. 
Marking LUKS
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 unusable.
Activating temporary device using old LUKS header.
Key slot 0 unlocked.
Cannot get info about
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.
Activation of temporary devices failed.

Now it says that the device is not a luks device anymore. I do not have
a header backup (I'm an idiot) what I do have is the luksDump
information and I have not rebooted my system:

LUKS header information
for /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256
MK digest:     	1f 82 26 80 f4 41 4f b7 17 ed 45 b0 fc f7 f9 cc
4f ee c8 7a MK salt:       	a6 cb ed 6a 5c db 46 6a 87 a1 cb 5f
62 14 8b ea 50 a0 c9 0e 93 68 56 e3 be 4f 59 a1 7b a9 84 dd 
MK iterations: 	47000
UUID:          	2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7

Key Slot 0: ENABLED
	Iterations:         	188266
	Salt:               	a8 b6 30 8c 6a 8c f9 98 3f 1d 1d 1d
1c 22 87 b8 d1 ba 09 e5 63 06 e0 aa 1c fd d0 f9 d7 f7 3c 9c 
	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

Now can I recreate the header so I can move my data before trying to
reencrypt again?

Please Help me and any Help is appreciated!

Sincerely
Felix the Idiot

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [dm-crypt] help

[Felix Wagner]

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

OK, thanks!

On Thu, 25 Feb 2016 18:55:52 +0100
Milan Broz <gmazyland@gmail.com> wrote:

> Just adition to reencryption bug - the problem is to use dynamic path
> in /dev/ that uses UUID. This path/UUID disappears once reencrypt
> utility marks device non-LUKS (temporarily, in the middle of
> operation).
> 
> (The real bug is that reencrypt utility fails to recover properly in
> this situation, this path just cannot be used.)
> 
> So just using proper device (like /dev/sdb or so) and it should work.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [dm-crypt] help

[Milan Broz]

On 02/25/2016 06:49 PM, Felix Wagner wrote:
> I do have one more question. I recently updated my arch system and now
> whenever I luksOpen the mapped dev gets mounted automatically. Is this
> arch specific or cryptsetup?

cryptsetup never mounts any filesystem itself, so it is question
for Arch distro experts (I guess it is some crypttab/fstab/systemd magic).


Just adition to reencryption bug - the problem is to use dynamic path in /dev/
that uses UUID. This path/UUID disappears once reencrypt utility marks device
non-LUKS (temporarily, in the middle of operation).

(The real bug is that reencrypt utility fails to recover properly in this situation,
this path just cannot be used.)

So just using proper device (like /dev/sdb or so) and it should work.

Milan

Re: [dm-crypt] help

[Felix Wagner]

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

I do have one more question. I recently updated my arch system and now
whenever I luksOpen the mapped dev gets mounted automatically. Is this
arch specific or cryptsetup?

Sincerely
Felix



On Thu, 25 Feb 2016 18:20:55 +0100
Milan Broz <gmazyland@gmail.com> wrote:

> On 02/25/2016 06:05 PM, Felix Wagner wrote:
> > Hello,
> > 
> > thanks for your replies. Yea, any of those files DO NOT exist
> > anywhere on my fs (I checked with find). I think the process didn't
> > really start.
> > 
> > How do I continue then?  
> 
> ok, it is possible that you find a nasty bug...
> (using /dev/disk/uuid path seems to be not working).
> 
> Try this (replace <LUKS_device> and <backup_file> appropriately):
> 
> 1) backup current (invalidated) header to some file (just to be sure)
> 
> dd if=<LUKS_device> of=<backup_file> bs=512 count=2056
> 
> 2) recover magic string
> 
> echo -n -e 'LUKS\xba\xbe' | dd of=<LUKS_device> bs=1 seek=0
> conv=notrunc
> 
> ...
> and try to luksDump it, then luksOpen.
> 
> Milan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [dm-crypt] help

[Felix Wagner]

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


Hello,

thank you very much after completing these steps I can access
everything again. (Now creating backup headers for all LUKS devices)

Again, thank you very much !






On Thu, 25 Feb 2016 18:20:55 +0100
Milan Broz <gmazyland@gmail.com> wrote:

> On 02/25/2016 06:05 PM, Felix Wagner wrote:
> > Hello,
> > 
> > thanks for your replies. Yea, any of those files DO NOT exist
> > anywhere on my fs (I checked with find). I think the process didn't
> > really start.
> > 
> > How do I continue then?  
> 
> ok, it is possible that you find a nasty bug...
> (using /dev/disk/uuid path seems to be not working).
> 
> Try this (replace <LUKS_device> and <backup_file> appropriately):
> 
> 1) backup current (invalidated) header to some file (just to be sure)
> 
> dd if=<LUKS_device> of=<backup_file> bs=512 count=2056
> 
> 2) recover magic string
> 
> echo -n -e 'LUKS\xba\xbe' | dd of=<LUKS_device> bs=1 seek=0
> conv=notrunc
> 
> ...
> and try to luksDump it, then luksOpen.
> 
> Milan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [dm-crypt] help

[Ondrej Kozina]

Hi again,

so I'm afraid you've actually found quite ugly bug in 
cryptsetup-reencrypt utility. Nevertheless there's still hope for your 
data because I believe the utility haven't overwritten any data. Keep 
reading.

I tried to reproduce the behaviour you've experienced:

Whenever I run cryptsetup-reencrypt and try to reference the luks device 
by /dev/disk/by-uuid symlink the utility fails. What is worse is fact 
that after this kind of failure (which is first bug) it removed the log 
file and header backup after it marked "dirty" the luks header on your 
drive (which much worse)!

I'll take care of these bugs, please follow the steps Milan sent on the 
list to recover your header. In fact it's not deleted only dirtied by 
the reencrypt utility.

Regards
O.

Re: [dm-crypt] help

[Milan Broz]

On 02/25/2016 06:05 PM, Felix Wagner wrote:
> Hello,
> 
> thanks for your replies. Yea, any of those files DO NOT exist anywhere
> on my fs (I checked with find). I think the process didn't really
> start.
> 
> How do I continue then?

ok, it is possible that you find a nasty bug...
(using /dev/disk/uuid path seems to be not working).

Try this (replace <LUKS_device> and <backup_file> appropriately):

1) backup current (invalidated) header to some file (just to be sure)

dd if=<LUKS_device> of=<backup_file> bs=512 count=2056

2) recover magic string

echo -n -e 'LUKS\xba\xbe' | dd of=<LUKS_device> bs=1 seek=0 conv=notrunc

...
and try to luksDump it, then luksOpen.

Milan

Re: [dm-crypt] help

[Felix Wagner]

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

Hello,

thanks for your replies. Yea, any of those files DO NOT exist anywhere
on my fs (I checked with find). I think the process didn't really
start.

How do I continue then?



On Thu, 25 Feb 2016 17:37:22 +0100
Milan Broz <gmazyland@gmail.com> wrote:

> On 02/25/2016 04:08 PM, Felix Wagner wrote:
> > Hello,
> > 
> > I tried to reencrypt my device today and was way too eager to do it
> > without reading everything. Heres what I did:
> > 
> > 'cryptsetup-reencrypt -v -c aes-xts-plain64 -s
> > 512 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> > Reencryption will change: volume key, set cipher to aes-xts-plain64.
> > Enter passphrase for key slot 0:
> > Key slot 0 unlocked.
> > LUKS header backup of
> > device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> > created. Data offset for detached LUKS header must be either 0 or
> > higher than header size (4036 sectors). Creation of LUKS backup
> > headers failed.
> > 
> > So i thought well It didn't work so lets try again:
> > 
> > cryptsetup-reencrypt -v -c
> > aes-xts-plain64 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> > Reencryption will change: volume key, set cipher to aes-xts-plain64.
> > Enter passphrase for key slot 0:
> > Key slot 0 unlocked.
> > LUKS header
> > backup of
> > device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> > created. New LUKS header for
> > device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> > created. Activated keyslot 0. 
> > Marking LUKS
> > device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> > unusable. Activating temporary device using old LUKS header.
> > Key slot 0 unlocked.
> > Cannot get info about
> > device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.
> > Activation of temporary devices failed.
> > 
> > Now it says that the device is not a luks device anymore. I do not
> > have a header backup (I'm an idiot) what I do have is the luksDump
> > information and I have not rebooted my system:  
> 
> Do you have these files still in current directory?
> 
> LUKS-ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.log
> LUKS-ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.new
> LUKS-ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.org
> 
> If so, save them. *.log is reencryption log. If you run reencrypt
> in directory with these files, reencryption will resume.
> 
> If it did not started yet, *.org is header backup and you can
> use it to restore old device state.
> 
> (If reencryption already started some part of device is already
> reencrypted so you have to finish that operation.)
> 
> Please can you paste here content of the *.log file?
> (It is text file containing reencryption context.)
> 
> (In theory, if reencryption did not really started yet the initial
> header is still on-device, just with different magic string, so
> recovery could be still possible just with simple on-disk edit.)
> 
> Milan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [dm-crypt] help

[Milan Broz]

On 02/25/2016 04:08 PM, Felix Wagner wrote:
> Hello,
> 
> I tried to reencrypt my device today and was way too eager to do it
> without reading everything. Heres what I did:
> 
> 'cryptsetup-reencrypt -v -c aes-xts-plain64 -s
> 512 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> Reencryption will change: volume key, set cipher to aes-xts-plain64.
> Enter passphrase for key slot 0:
> Key slot 0 unlocked.
> LUKS header backup of
> device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 created.
> Data offset for detached LUKS header must be either 0 or higher than
> header size (4036 sectors). Creation of LUKS backup headers failed.
> 
> So i thought well It didn't work so lets try again:
> 
> cryptsetup-reencrypt -v -c
> aes-xts-plain64 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> Reencryption will change: volume key, set cipher to aes-xts-plain64.
> Enter passphrase for key slot 0:
> Key slot 0 unlocked.
> LUKS header
> backup of device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> created.
> New LUKS header for
> device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 created.
> Activated keyslot 0. 
> Marking LUKS
> device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 unusable.
> Activating temporary device using old LUKS header.
> Key slot 0 unlocked.
> Cannot get info about
> device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.
> Activation of temporary devices failed.
> 
> Now it says that the device is not a luks device anymore. I do not have
> a header backup (I'm an idiot) what I do have is the luksDump
> information and I have not rebooted my system:

Do you have these files still in current directory?

LUKS-ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.log
LUKS-ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.new
LUKS-ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.org

If so, save them. *.log is reencryption log. If you run reencrypt
in directory with these files, reencryption will resume.

If it did not started yet, *.org is header backup and you can
use it to restore old device state.

(If reencryption already started some part of device is already
reencrypted so you have to finish that operation.)

Please can you paste here content of the *.log file?
(It is text file containing reencryption context.)

(In theory, if reencryption did not really started yet the initial
header is still on-device, just with different magic string, so recovery
could be still possible just with simple on-disk edit.)

Milan

Re: [dm-crypt] help

[Ondrej Kozina]

Hi Felix,

don't loose all hope yet!

On 02/25/2016 04:08 PM, Felix Wagner wrote:
> So i thought well It didn't work so lets try again:
>
> cryptsetup-reencrypt -v -c
> aes-xts-plain64 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> Reencryption will change: volume key, set cipher to aes-xts-plain64.
> Enter passphrase for key slot 0:
> Key slot 0 unlocked.
> LUKS header
> backup of device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
> created.

^^^^^^^^
First of all, you actually may have the LUKS header backup! The 
cryptsetup-reencrypt created one for you automatically. Look for 
LUKS-foobar.org file in the directory where you initiated the 
cryptsetup-reencrypt.

If... (well rather big fat _IF_ because this is really important) the 
reencryption didn't write any data yet you may restore your LUKS header 
using the .org backup created by cryptsetup-reencrypt.

But again _don't_ do the header recovery unless you're 100% sure that 
reencryption didn't write (aka already reencrypted) any ciphertext 
sectors! So, what's in your reencrypt log file (look for LUKS-foobar.log 
in same directory where is also the header backup)?

Regards
Ondra

[dm-crypt] help

[Felix Wagner]

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

Hello,

I tried to reencrypt my device today and was way too eager to do it
without reading everything. Heres what I did:

'cryptsetup-reencrypt -v -c aes-xts-plain64 -s
512 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
Reencryption will change: volume key, set cipher to aes-xts-plain64.
Enter passphrase for key slot 0:
Key slot 0 unlocked.
LUKS header backup of
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 created.
Data offset for detached LUKS header must be either 0 or higher than
header size (4036 sectors). Creation of LUKS backup headers failed.

So i thought well It didn't work so lets try again:

cryptsetup-reencrypt -v -c
aes-xts-plain64 /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
Reencryption will change: volume key, set cipher to aes-xts-plain64.
Enter passphrase for key slot 0:
Key slot 0 unlocked.
LUKS header
backup of device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7
created.
New LUKS header for
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 created.
Activated keyslot 0. 
Marking LUKS
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7 unusable.
Activating temporary device using old LUKS header.
Key slot 0 unlocked.
Cannot get info about
device /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7.
Activation of temporary devices failed.

Now it says that the device is not a luks device anymore. I do not have
a header backup (I'm an idiot) what I do have is the luksDump
information and I have not rebooted my system:

LUKS header information
for /dev/disk/by-uuid/2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
MK bits:       	256
MK digest:     	1f 82 26 80 f4 41 4f b7 17 ed 45 b0 fc f7 f9 cc
4f ee c8 7a MK salt:       	a6 cb ed 6a 5c db 46 6a 87 a1 cb 5f
62 14 8b ea 50 a0 c9 0e 93 68 56 e3 be 4f 59 a1 7b a9 84 dd 
MK iterations: 	47000
UUID:          	2ea1bb9e-a4a0-48c8-bc67-a694fa6c8cf7

Key Slot 0: ENABLED
	Iterations:         	188266
	Salt:               	a8 b6 30 8c 6a 8c f9 98 3f 1d 1d 1d
1c 22 87 b8 d1 ba 09 e5 63 06 e0 aa 1c fd d0 f9 d7 f7 3c 9c 
	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

Now can I recreate the header so I can move my data before trying to
reencrypt again?

Please Help me and any Help is appreciated!

Sincerely
Felix the Idiot

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[dm-crypt] help

[Eugen Rogoza]

Re: [dm-crypt] Help

[Arno Wagner]

If you cannot afford to lose the data, then surely you have a 
backup (see FAQ) and a header backup (see FAQ)? Having a single
copy of vital data on an unreliable storage medium is not a
good idea, encrypted or not. 

Now, if you really did luksFormat a device with LUKS data on
it, then all that data is permanently gone (rather obvious, 
also see FAQ). If not, then maybe describe what happened so 
that it is possible for us to reconstruct it?

Arno

On Fri, Apr 20, 2012 at 04:58:46PM +0100, Simon Bing wrote:
> I used cryptsetup to perform the following function
> 
> cryptsetup -y --cipher aes-xts-plain --key-size 512 luksFormat /dev/sdb1
> 
> An error occured saying it couldnt be performed which i pretty much ignored
> and just thought i won't bother.  I did note that it mentioned about kernel
> compatability though.  The drive appears to be encrypted and wont accept
> the passphrase set.  This has just under 1.5 tb of information i can't
> afford to loose.  Do you have any solutions, i have looked online but am
> absolutely stuck
> 
> Cheers
> 
> Si

> _______________________________________________
> 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
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

[dm-crypt] Help

[Simon Bing]

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

I used cryptsetup to perform the following function

cryptsetup -y --cipher aes-xts-plain --key-size 512 luksFormat /dev/sdb1

An error occured saying it couldnt be performed which i pretty much ignored
and just thought i won't bother.  I did note that it mentioned about kernel
compatability though.  The drive appears to be encrypted and wont accept
the passphrase set.  This has just under 1.5 tb of information i can't
afford to loose.  Do you have any solutions, i have looked online but am
absolutely stuck

Cheers

Si

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