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]>
"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