On Mon, 16 Feb 2009 17:28:59 +0100
Arno Wagner <arno@xxxxxxxxxxx> wrote:
> On Mon, Feb 16, 2009 at 09:59:19AM +0100, orinoco wrote:
> > OMG!
> > I found the error and I fear an irrevocable data loss:
> >
> > With the update the kernel switched the internal /dev/sdXX order of
> > the hard disks - again. Unfortunately the former /dev/sdb5 was
> > mounted in crypttab as encrypted swap with /dev/random as key
> > before all other devices. And then I did reboot with the new
> > kernel ... :-((((((( I did address the swap partitions with
> > the /dev/sdXX name because there was not uuid in ls
> > -la /dev/disk/by-uuid/ for them .... :-((((( That explains
> > everything ... but I fear ...
> >
> > If anyone has any idea how to restore this partition
> > I guess he would be a candiate for nobel price ...
>
> No nobel price, but the real question is how much of the swap
> was written to and were the data was written. I have absolutely
> no idea how swap space is used with regard to where stuff gets
> swapped to, but if you swap usage is low, most of the LUKS
> header may still be intact.
>
> There is also the swap signature to be considerd. I do not know
> exactly what it looks like, but an experiment with a file of
> zeros it looks to me like only the first 4096 bytes hold
> management info and that of these very little is written
> except onactual swap usage.
>
> >From an other such discussion here, what you need is at least
> one key and all its salts, as well as the salt of the master
> key. The rest of the header is, I think, less-critical
> and may be reconstructable.
>
> So have a look at the LUKS header spec and see what is still there
> on your partition.
With ... I get ...
# cryptsetup luksDump /dev/sdb5
LUKS header information for /dev/sdb5
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 1032
MK bits: 128
MK digest: XX (x20)
MK salt: XY (x16)
XZ (x16)
MK iterations: 10
UUID: <uuid-of-failure-device>
Key Slot 0: ENABLED
Iterations: 247257
Salt: YX (x16)
YY (x16)
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
-----------------------------------
# cryptsetup luksOpen /dev/sdb5 encdisk0
Enter LUKS passphrase:
Enter LUKS passphrase:
Enter LUKS passphrase:
Aufruf fehlgeschlagen: No key available with this passphrase.
-----------------------------------
The swap entry (now deactivated) in /etc/crypttab that caused the
problem did look like this:
# <target name> <source device> <key file> <options>
# swpenc /dev/sdb5 /dev/random
swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256
-----------------------------------
I guess it was activated a few times with every reboot until I noticed
the cause.
> Unfortunately it looks like the LUKS homepage at
> http://luks.endorphin.org/
> is down at the moment. However it seems the PDF with
> the on-disk specification is also available here:
> http://code.google.com/p/cryptsetup/wiki/Specification
>
> Rough overview is the figure directly under 1. Overview.
> The actual on-disk header in detail is in Figure 1,
> and the keyslod description is in Figure 2.
I'm going through this, struggling how to apply ...
> I think you absolutely need the fields at offsets
> 112 and 132, in addition to a keyslot with
> intact salt data and the actual key-block intact.
As far as I can see from luksDump there is
MK digest and MD salt. But there seems to be something wrong with it.
> There may be other fields you absolutely need, but
> 32-64 bits or so can be brute-forced today without too
> much hassle, depending on what actually need to be done
> for a try. This still costs significant effort and
> may cause significant cost.
>
> The other thing is to think about how much your data is
> worth. It may be cheaptest to regard this as a lost
> cause from the beginning.
I would consider it "nice to have it back" and worth some effort.
It isn't (or wasn't) vital information.
> Although I would recomment at least
> one in-detail look at the header. It may basically still
> be there.
There is a "complete" header information I get from luksDump (see
above), but it does not seem to work with luksOpen and the original
passphrase.
BTW I noticed that my system keeps mixing the sdXX device order.
After a reboot it changed again.
regards
Carsten
--
Mail Encryption welcome! - Mail Verschlüsselung erwünscht!
Ask for public key! - öffentlicher Schlüssel auf Anfrage!
