that's exactly what i like to see:-)))
i'd realy nice to include it into python-crypto! is there any progess in
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?
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 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)
Levente "Si vis pacem para bellum!"