it's amazing!
that's exactly what i like to see:-)))
i'd realy nice to include it into python-crypto! is there any progess in
this way?
did you try it with freeotfe? so it can open a file as a container for a
file not a file as container for a filesystem?
thanks again!

John Lenz wrote:
> 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
> 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 implementation in the patch because I plan
> on submitting it for inclusion in python-crypto.  To use the patch, you
> need to copy,, and into the datahandler
> directory.
> 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
> self.luks.truncate(0)
> self.luks.encrypt_data(...)
> 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
> delete_key.
> 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.
>  Etc...
> 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)
> John

  Levente                               "Si vis pacem para bellum!"

Reply via email to