From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4
Date: Fri, 28 Feb 2014 22:46:01 +0100 [thread overview]
Message-ID: <20140228214601.GA23681@tansi.org> (raw)
In-Reply-To: <fc21bc26e7cacfef060f4f971ab233a6.squirrel@ssl.verfeiert.org>
On Fri, Feb 28, 2014 at 22:26:03 CET, Sven Eschenberg wrote:
> Just out of curiosity,
>
> Isn't it possible (yet) to override header fields during luksopen? If not,
> wouldn't it make sense to add something like that in future versions? I
> think it could be of great help when the header is partly damaged, to be
> able to override things without using a hex editor.
I doubt this makes much sense. From what I have seen,
usually the magic string at the start is gone as well,
and then there is a real risk that people try this with
the wrong data. Using a hex-editor is not that hard and
using a hex-dumper is basically required to get any
reasonable form of diagnostics. Even the keyslot-
checker is basically a specialized hexdump tool.
> I am aware that one could use the non-LUKS mode to open a LUKS device by
> passing all required parameters, admitted. But a mode where one can use
> what's in the header and override single fields could be interesting. Once
> the correct params are determinde this way, one could maybe add an option
> to repair the header with the given replacements (Maybe by adding the
> option to reencryt?).
>
> Just some thoughts that crossed my mind.
I doubt this really helps. Also remember that finding out what
actually broke the header is important, so fiddeling around
with an opaque header and commandline arguments to cryptsetup
after you have analyzed a hexdump strikes me as not that effective.
I do understand that hex-editing is akward for many people,
but I do not think this makes it any better or clearer.
One thing that would help a bit is a header layout with
hex offsets. I think I am going to add that to the FAQ.
Admittedly, the whirlpool problem (BTW, now documented in
FAQ Item 8.3) would be easy to solve with your proposal.
Arno
--
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
next prev parent reply other threads:[~2014-02-28 21:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 14:39 [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4 Milan Broz
2014-02-27 17:30 ` Thomas Bächler
2014-02-28 7:51 ` Milan Broz
2014-02-28 11:29 ` Milan Broz
2014-02-28 11:38 ` Arno Wagner
2014-02-28 21:26 ` Sven Eschenberg
2014-02-28 21:46 ` Arno Wagner [this message]
2014-02-28 22:06 ` Sven Eschenberg
2014-02-28 23:27 ` Arno Wagner
2014-03-01 7:39 ` Sven Eschenberg
2014-03-01 8:35 ` Milan Broz
2014-03-01 11:32 ` Sven Eschenberg
2014-03-01 16:50 ` Heinz Diehl
2014-03-01 19:44 ` Arno Wagner
2014-03-02 7:35 ` Heinz Diehl
2014-03-02 15:17 ` Arno Wagner
2014-03-01 13:50 ` Arno Wagner
2014-02-27 21:44 ` Heinz Diehl
2014-02-27 22:36 ` Arno Wagner
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=20140228214601.GA23681@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.