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 support. 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. 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: > > http://www.cs.wisc.edu/~lenz/luks/ > http://www.cs.wisc.edu/~lenz/luks/rvl.diff > > (You also need to redownload luks.py 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 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 > > 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/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 > kernel, but....). > > John > > > -- 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
