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 problem. Thanks for looking into it! -- Erik Grinaker <[EMAIL PROTECTED]> http://erikg.codepoet.no/ "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 enthusiastic about." -- Albert Einstein
