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

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

 




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?
_______________________________________________
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