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 luks.py because I made a small change to
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 io.py 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
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/base.py, 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