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. > > LUKS seems to have alot of possibilities, but I'm not sure if it makes > > sense to implement them all in Revelation. For example, I see no point > > in having a preference for changing the encryption algorithm - we should > > pick one that is secure enough and use it, and if it's broken we should > > change it in a future version. In this case LUKS does give us > > backwards-compatability for free, though. LUKS also has lots of fun > > stuff like multiple keys and key revocation, but fully supporting it > > would mean adding complexity both in the user-interface and the code. So > > we would probably need to pick a basic subset of functionality to > > support. > > Yeah, the latest patch on my server implements support for adding and > deleting a key, but just includes defaults for encryption settings and > the like. The only non-obvious entry is the number of iterations to use > for the key, which I am currently prompting for on the change key > dialog. I guess we could just choose a default of say 4000 or so (which > is what the textbox currently defaults to) Yeah, I think we should use a default for the key iterations. 4000 should be sufficient, but we might as well up it to 10000. I'll consider support for adding/deleting keys, but I suspect not many people will have any use for this. Keep it simple, y'know. > > It does seem very cool though, and I'll play around with it in a few > > weeks when I can focus on Revelation again. In any case I will add your > > file handler to allow for importing and exporting of LUKS data files, > > but I'll have to take a closer look before deciding to use it by > > default. > > > > Yeah, I have currently switched over to using revelation with my patch > and the LUKS format for all my passwords and revelation use. I have > even added a second key using the GUI. If you don't switch over, I > would like a preference or command option or something to use the LUKS > format as the default. There's a big probability that I'll use LUKS by default, but I need to play with it a bit first. -- 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
