On Mon, 2006-05-29 at 12:39 -0500, John Lenz wrote:
> 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.
> >> 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.
> > 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.
Awesome! Unless this has any problematic side-effects, such as screwing
things up for non-standard implementations, this should solve the
Thanks for looking into it!
Erik Grinaker <[EMAIL PROTECTED]>
"We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
-- Albert Einstein