Re: blkid and aes-cbc-plain/aes-cbc-essiv:sha256

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx 
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 
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux