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 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 > directory. > > http://www.cs.wisc.edu/~lenz/luks > http://www.cs.wisc.edu/~lenz/luks/rvl.diff > http://luks.endorphin.org/ > > 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!"
