From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] blkid and aes-cbc-plain/aes-cbc-essiv:sha256
Date: Tue, 13 Mar 2012 19:34:19 +0100 [thread overview]
Message-ID: <20120313183419.GA20313@tansi.org> (raw)
In-Reply-To: <CAFnMBaTsYQ3MSAOcajnqQyFyZYWAHUOy8awa7RuC408YYp+fJA@mail.gmail.com>
On Tue, Mar 13, 2012 at 12:14:47PM -0400, .. ink .. wrote:
> > That said, I agree that guessing is not the right approach.
> > What if, for example, there is an old first block
> > lying around, but the new crypto-container is at an offset?
> > In that case not even the cipher or the key might be the same!
> >
> > Arno
> >
> >
> ok, that makes sense but this raises a fundamental problem with plain
> volumes, a problem that must have had a solution since the type was in use
> when luks wasnt around.My problem was a specific problem from a general
> problem.
Simple: Put the right stuff into /etc/fstab and maybe /etc/crypttab
and/or mount manually. Not everything needs to be automated.
> Lets say somebody uses cryptsetup tool directly to create a plain mapper
> with options they think are appropriate for the volume, how will this
> person know they have used the right options? say the right mode or did
> not mistype a character in the passphrase?
Simple again: They created the volume, and if they did it with
non-default values, then if mounting fails they have to make
sure passphrase _and_ all other parameters are correct. In
practice, you use the defaults unless you have a good reason
not to. If you use something else, you will make sure that
you remember, e.g. by encapsulating it in a script or writing
it down. Only the passphrase must be kept secret.
> If it is known that the volume has a file system, then looking for file
> system signature is the most logical thing to do(this is the approach i
> took with available tools). If they cant find the signature then they can
> assume one or more of the options is wrong. If they find it then they can
> assume the options are correct. If this way is wrong, then what is the
> right way?
There is no right way. The user is the only one that knows what
is in there.
> what is the recommended way and what tools are to be used to check if a
> created plain mapper is created with proper options?
Remembering how it was created. There is no other "correct" way.
> How did distros back in the day when luks wasnt around and when they were
> using plain volumes checked to make sure a user created the plain mapper
> with a proper a passphrase?
In those days, distros generally did not help the user with encrypted
volumes. The best available was that the user had to write their
own mapping scripts or maybe cpuld manually make an entry in something
like /etc/crypttab. There certainly was no automatization and there
usually is none today. Or if you look at a recent Ubuntu bug, there
are some attempts at automaization that do more harm than good.
On a meta-layer, what you want to do is take the competent
system administrator that knows what he/she is doing and how
they configured their system out of the loop. That is a very
Windows or Mac thing to do, but not a very Unix one. Unix gives
you the tools and lets you decide how you want to use them.
That approach is not very compatible with automating things in
a default way.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
next prev parent reply other threads:[~2012-03-13 18:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 21:30 [dm-crypt] blkid and aes-cbc-plain/aes-cbc-essiv:sha256 .. ink ..
2012-03-12 22:36 ` Milan Broz
2012-03-13 1:03 ` .. ink ..
2012-03-13 14:46 ` Sven Eschenberg
2012-03-13 14:56 ` Arno Wagner
2012-03-13 16:14 ` .. ink ..
2012-03-13 18:34 ` Arno Wagner [this message]
2012-03-13 17:49 ` Javier Juan Martínez Cabezón
2012-03-13 18:38 ` 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=20120313183419.GA20313@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.