I agree with a previous poster on this list, that the LUKS on disk file
format should be used for revelation.  The LUKS disk format uses several
standards (like RFC2898) that have been examined for cryptographic
weaknesses by cryptographers.  It also implements all the features the new
Revelation format proposes to add.  Files are readable on linux by the
kernel, and on Windows using FreeOTFE.

So, I have created a python class to read, write, and create LUKS files. 
Files created with my class can be read by the linux kernel, and files
created by the kernel can be accessed by my python class.  The luks.py
class I implemented has nothing to do with Revelation, it just reads and
writes from a file.  So I also patched Revelation to use my new class (it
stores RevelationXML in the data portion of the LUKS file).  The patch is
against revision 531 of the revelation/trunk SVN.

I did not include the luks.py implementation in the patch because I plan
on submitting it for inclusion in python-crypto.  To use the patch, you
need to copy luks.py, AfSplitter.py, and PBKDFv2.py into the datahandler


Some Revelation implemetation details follow:
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

def __init__(self):
  self.luks = None

def import_data(self,...):
  self.luks = ...

def export_data(self,...):
  if self.luks == None:
    self.luks = create ....

  # use self.luks to encrypt the data
  # Note, if the file has already been created, we do NOT need the
password to be passed in

Note that the only thing the LuksFile keeps in memory is the header, and
it is easy to in the export: just call something like this
So the LuksFile class can be the object revelation uses to cache to keep
around the header information.

2) LUKS supports up to 8 passwords to unlock the data.  All the
information about these are stored in the header... so for revelation to
support multiple passwords, it needs to ask for a password when importing
(and then tries all 8 slots).  When exporting, it needs to use the header
it loaded while importing, so it doesn't clobber all the other keys
besides the one that was currently used to unlock the file.  If problem 1)
is implemented, it also solves this problem since we preserve the header.

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

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.  Otherwise, a small python script can be written
which asks for the options and creates a LUKS revelation file with an
empty xml data portion.  Several of these options have trade-offs: the
number of stripes increases the file size but also increases the security
when trying to delete a key.  The number of iterations impacts the amount
of time a dictionary attack would take, but makes loading slightly slower.

In any case, using the LUKS file will allow you to focus more on the
revelation UI and XML format, while using a standard and secure on disk
format (that can also be debugged and read using tools besides revelation)


Reply via email to