[dm-crypt] [ANNOUNCE] cryptsetup 1.6.4

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sat Mar 1 08:39:44 CET 2014

Another things that crossed my mind:

Currently the FAQ states in respect to the whirpool problem, to do a
header backup prior to changing the header or using reencrypt. Wouldn't it
be better to make this a minimum requirement and recommend a full backup
instead? Imagine for whatever reason some portion after the payload offset
gets damaged/overwritten, be it by mixing up numbers or because of any
unobvious bug somewhere.



On Sat, March 1, 2014 00:27, Arno Wagner wrote:
> On Fri, Feb 28, 2014 at 23:06:30 CET, Sven Eschenberg wrote:
>> On Fri, February 28, 2014 22:46, Arno Wagner wrote:
>> > 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.
>> Okay, that's true. I personally do use a hexeditor too, I have to admit,
>> just thought it could help less experienced people. Then again, if
>> people
>> fail to use a hex editor chances are big they make things worse. I guess
>> I
>> didn't think this through long enough.
> I have a _lot_ of experience with students, some not so bright
> or experienced ;-)
>> >> 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.
>> That's absolutely true, indeed.
>> >
>> > 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.
>> Good point, I'd propose adding this to the luks on disk format document
>> as
>> well. If you cannot convert HEX<->DEC inside your head having the hex
>> offsets at disposal helps alot. I admit, I used a converter when I
>> edited
>> my headers lately.
> Me too. For the time being, there now is a nice hex + dec table
> in FAQ Item 6.12
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

More information about the dm-crypt mailing list