From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?
Date: Sat, 2 Jul 2016 20:55:49 +0200 [thread overview]
Message-ID: <20160702185548.GA26509@tansi.org> (raw)
In-Reply-To: <577803E0.1050901@braegelmann.net>
Hi Bernd,
On Sat, Jul 02, 2016 at 20:11:44 CEST, Bernd Brägelmann wrote:
> Hi Arno,
>
> here the requested dump. Looks like the Master Boot Record with "55 aa"
> boot signature. The byterange of the luks mastersalt is basically empty.
Indeed.
> So all fucked up - I guess.
That is my take as well. Unless the header is in some
image-backup or the like somewhere else, there is no
way to recover this and it is not a question of money
either.
> BTW: What is your guess: Will my grandchildren be able to crack a
> 256-aes-xts file system. What is your guess? Should I long-term store
> the hard discs?
The best attack would be on the master-key directly, ignore
all that LUKS stuff. Lets also assume they have one block
with a known plaintest (e.g. a filsystem master-block) or
an empty inode).
If we assume quantum computing ever works for problems this
size (very, very doubtful), maybe the key could be cut down
to 128 bit.
2^128 is 3.4*10^38
I think we can safely forget that for the foreseable future.
It will need some "magic" to be discovered that is stronger than
quantum computing, or else there is no way the human race will
be able to recover your data from that disk. That is as it should
be, LUKS needs to be secure after all.
Of course, it is possible that AES will turn out to be
trivially breakable, but that seems rather unlikely as well.
Sorry I have no better news, but security and accessibility
are naturally at odds. Just read the items on backup in FAQ
Section 6 for the next time. LUKS is in principle very safe
and reliable, but the header and keyslots are its one weak
spot. There has been a lot of discussion here about doing
some automatic header backup, but so far no good solution has
presented itself.
Regards,
Arno
> Cheers,
>
> Bernd
>
>
> braegel1 ~ # head -c 1k /dev/md2 | hd
> 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0
> |................|
> 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00
> |...|.........!..|
> 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75
> |....8.u........u|
> 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b
> |.........|...t..|
> 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00
> |L.....|.........|
> 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> *
> 000001b0 00 00 00 00 00 00 00 00 70 57 07 00 00 00 00 00
> |........pW......|
> 000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> *
> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
> |..............U.|
> 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> |................|
> *
> 00000400
>
>
> --
> Bernd Brägelmann FA für Radiologie
> Robert-Koch-Str. 42 - 28277 Bremen
> fon: +49 15141457796 PGP: BCA853F8
>
>
> On 07/02/2016 06:14 PM, Arno Wagner wrote:
> > Hi Bernd,
> >
> > On Sat, Jul 02, 2016 at 12:42:27 CEST, Bernd Brägelmann wrote:
> >> Hi Arno,
> >>
> >> thanks for answering. I created the partition table within /dev/md2 and
> >> the raid is still working.
> >
> > Ok, so we ignore the RAID.
> >
> >> My current last hope is that the salt might be in a redundant part of
> >> the raid array.
> >
> > Those will have gotten synced immediately, RAID inconsistencies
> > live only for as long as they are in the write queue. No hope
> > there.
> >
> > Ok, the LUKS superblock (or what is left of it) will be at
> > the start of /dev/md2. Can you post the following (will
> > not compromise your datta, that is protected by the
> > passphrase(s)):
> >
> > head -c 1k /dev/md2 | hd
> >
> > This allows a manual look of what is left of the LUKS header.
> >
> > Regards,
> > Arno
> >
> _______________________________________________
> 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
next prev parent reply other threads:[~2016-07-02 18:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-02 6:33 [dm-crypt] Incidentaly partitioned LUKS device - header lost? Bernd Brägelmann
2016-07-02 10:20 ` Arno Wagner
2016-07-02 10:25 ` Arno Wagner
2016-07-02 10:42 ` Bernd Brägelmann
2016-07-02 16:14 ` Arno Wagner
2016-07-02 18:11 ` Bernd Brägelmann
2016-07-02 18:55 ` Arno Wagner [this message]
2016-07-02 20:06 ` Bernd Brägelmann
2016-07-02 21:53 ` Arno Wagner
2016-07-03 20:40 ` Michael Kjörling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160702185548.GA26509@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.