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). John
