On Mon, May 8, 2006 8:05 am, Farkas Levente said:
> John Lenz wrote:
>> I agree with a previous poster on this list, that the LUKS on disk file
>> format should be used for revelation. The LUKS disk format uses several
>> standards (like RFC2898) that have been examined for cryptographic
>> weaknesses by cryptographers. It also implements all the features the
>> Revelation format proposes to add. Files are readable on linux by the
>> kernel, and on Windows using FreeOTFE.
> a few more technical question:
> - did you use the same magic as in luks partition?
Uh, I don't think LUKS has a partition number (that would be stored in the
partition table). Instead, the first 4 bytes of a luks file or partition
are "LUKS". The kernel only knows to check it as a LUKS partiton or file
because you tell it to (in a script in /etc/init.d or /etc/cyrpttab or on
the command line)
> - if yes how can the system (kerenl, driver) know wether it's a luks
> file or luks filesystem ie. it contains only a file or a filesystem?
The kernel does not care what is in the data portion... Once the
encryption is set up, the decrypted data section of the LUKS file is
accessable from the /dev/mapper/<name> file. So the kernel does not
enforce any restrictions on the data, whatever is there gets exported into
that file. You can access this data directly, or you can point mount at
that file, telling mount that there exists a filesystem in the
/dev/mapper/<name>. Then, another linkage is setup between
/dev/mapper/<name> and wherever you mount the partition.
So, the kernel only knows that there exists a filesystem there because you
tell it, either on the command line or in /etc/fstab