Re: [dm-crypt] blkid and aes-cbc-plain/aes-cbc-essiv:sha256

[".. ink .." <mhogomchungu@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

> 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.

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?

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?

what is the recommended way and what tools are to be used to check if a
created plain mapper is created with proper options?

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?

[-- Attachment #2: Type: text/html, Size: 1643 bytes --]