All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] [ANNOUNCE] cryptsetup 1.6.4
Date: Sat, 1 Mar 2014 14:50:41 +0100	[thread overview]
Message-ID: <20140301135041.GC395@tansi.org> (raw)
In-Reply-To: <efa6ae0d61d5c8191398549351e4a882.squirrel@ssl.verfeiert.org>

Well, yes. But anybody careful or having read and understood
the warnings in the FAQ will have a full backup anyays. Anybody
that runs without backup is unlikely to make one now. Doing 
backup is sort of like working safely: It is a state of mind. 
One remark is not going to make people careful that are careless.

But I will add it nonetheless.

Arno

On Sat, Mar 01, 2014 at 08:39:44 CET, Sven Eschenberg wrote:
> 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.
> 
> Regards
> 
> -Sven
> 
> 
> 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@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@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> 
> 
> _______________________________________________
> 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

  parent reply	other threads:[~2014-03-01 13:50 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
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 [this message]
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=20140301135041.GC395@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.