Erik Grinaker wrote:
> On Sun, 2006-05-28 at 14:15 -0500, John Lenz wrote:
>> Erik Grinaker wrote:
>>> Using LUKS would make it difficult to identify a Revelation file, as any
>>> LUKS-file has the same header format. We would have to rely on an
>>> arbitrary filename extension, which seems suboptimal. But I'm
>>> considering changing Revelation to just work against a hidden password
>>> database in the users home-directory and remove most of the file-related
>>> UI and functionality, which should make this mostly a non-issue.
>> The LUKS header does include a UUID to make each file/partition whatever
>> unique.  We might be able to do something with that...  In any case, if
>> you provide a password, we can open up the LUKS data part and check that
>> the first few bytes are <?xml ...> or whatever.  We just won't be able
>> to check before a password is inputed.
> Yeah, but I'm thinking more like a magic string to register in the fd.o
> MIME database etc, so that nautilus will recognize it and Revelation
> will be used to open the file.

Actually, we can fix a location for a custom Revelation string.

The way LUKS works is the LUKS header contains an offset where the raw
data starts.  Currently, this is calculated by finding the end of the
key material, and rounding up to the nearest block size (size the start
of the data needs to be aligned).

We could insert an extra block after the key material, but before the
first data block.  The LUKS implementations would still work, because
the format specifies that you look up the start of the data from the
offset in the header.  Each key stores its own offset, and its size.  So
all LUKS implementations (including my class) would completely ignore
that extra block between the end of the key material and the start of
the data.

Actually, each key in the header also includes the offset the actual key
material is is located at.  So we could also insert a block between the
LUKS header and the start of all the key material.

Each block is 512 bytes, so there is more than enough space to store
whatever data you want.

Also, if we didn't want to insert blocks, we could store info between
the end of the header or end of the key material and the end of the
block they are in.  (Since all these things round up to the nearest
block, there is some leftover space).


Reply via email to