Sorry for leaving you hanging like this, but I've been very busy with
other stuff lately. But I'm starting to get some free time now, and I
expect to pick up Revelation development again in a couple of weeks.

I'm initially positive to using LUKS for encryption, and really
appreciate the work you've done. A few thoughts:

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.

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

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

On Wed, 2006-05-17 at 20:39 -0500, John Lenz wrote:
> Ok, I recently updated my patch to implement many of the things below,
> mainly just GUI updates over the previous version:
> (You also need to redownload because I made a small change to
> it)
> On Mon, 2006-05-08 at 01:22 -0500, John Lenz wrote:
> > 1) LUKS is designed to edit an existing file.  This is done by keeping
> > around the LUKS header, and only modifying the data portion.  Currently,
> > because of the API revelation uses, every time the file is saved it
> > creates a new LUKS header and file.  What I would like to see is some way
> > to preserve the header between the import_data and export_data functions. 
> > I don't think something like this will work, but you get the idea
> > 
> Ok, I implemented this by storing it in the RevelationLUKS class.  I had
> to make a few changes to so that when closing a file and opening a
> new one, it closed the info in the class.  You can now have a LUKS file
> with multiple passwords.  Typing any of the passwords into revelation
> will open the file (which is pretty cool!), and when saving all the
> password slots get written out.
> > 
> > 3) Some GUI for adding new passwords and deleting passwords would be nice
> > to have.  These are all operations on a header that was loaded during 1),
> > and all are just single function calls into the LuksFile class...
> > set_key(index, password) delete_key(index).  They will operate on the
> > header in memory, and during the export it will pick up the modified
> > header and write that to disk.  Otherwise, a simple 10 line python script
> > can be written to load the file into my luks class, and call set_key or
> > delete_key.
> I implemented this in the "change password" and "delete password" menu
> items.  The password change now asks for a slot and the number of
> iterations (more about iterations later).  I added a few blank methods
> to datahandler/, and implemented them for RevelationLUKS.
> > 
> > 4) Several of the options passed when creating the LUKS image would be
> > nice to be able for the user to select.  (Again, these are stored in the
> > header so they would only need to be specified when creating the file). 
> > The encryption algorithm to use (I pick aes, but LUKS supports blowfish
> > and cast5 and anything else python-crypto supports), the hash algorithm
> > used, the number of stripes when writing splitted encrypted master keys,
> > the number of iterations of PBKDFv2 are all options.  I picked some
> > defaults, but they are easy to change by just passing different arguments
> > into the LUKS class.  
> > 
> This I have not yet done:  I am not sure if these options should be
> prompted for when a new file is created, or when a new file is saved for
> the first time.  Also, which options to prompt for... could probably
> prompt for cipher and keysize together (AES128, AES256, Blowfish, etc
> (except blowfish can have any keysize between 32 and 448 bits...)).
> Some options might need explaining like # of key stripes.  Mode should
> probably always be "cbc-essiv:<hash>" because it is stronger and only
> very slightly slower (only really noticeable when using the encryption
> on a hard disk).
> Lastly, when changing a password I do prompt for the number of
> iterations.  This is the number of iterations of PBKDFv2 (RFC2898).  The
> cryptsetup-luks for linux calculates this value by benchmarking the
> PBKDFv2 algorithm on the users computer... it calculates the total
> number of iterations per second, and multiples that by a user supplied
> iteration time (which defaults to 1 second).  I haven't implemented this
> in python, but depending on how you want the GUI to turn out, it should
> be looked into.  Or just always default to say 4000 or 5000, which is
> enough to defeat most dictionary attacks if the randomness of the salt
> is high enough, but python crypto has a good random number generation so
> shouldn't be a problem (on linux, the salt comes from /dev/urandom,
> which could have problems depending on the randomness pool in the
> kernel, but....).
> John
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
enthusiastic about."
                                                  -- Albert Einstein

Reply via email to