Re: [rvl-list] Implement LUKS file format for Revelation
On Mon, 2006-05-29 at 12:39 -0500, John Lenz wrote: > Erik Grinaker wrote: > > On Sun, 2006-05-28 at 14:15 -0500, John Lenz wrote: > >> Erik Grinaker wrote: > >>> 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. > >> The LUKS header does include a UUID to make each file/partition whatever > >> unique. We might be able to do something with that... In any case, if > >> you provide a password, we can open up the LUKS data part and check that > >> the first few bytes are or whatever. > > > > Yeah, but I'm thinking more like a magic string to register in the fd.o > > MIME database etc, so that nautilus will recognize it and Revelation > > will be used to open the file. > > Actually, we can fix a location for a custom Revelation string. > > The way LUKS works is the LUKS header contains an offset where the raw > data starts. Currently, this is calculated by finding the end of the > key material, and rounding up to the nearest block size (size the start > of the data needs to be aligned). > > We could insert an extra block after the key material, but before the > first data block. The LUKS implementations would still work, because > the format specifies that you look up the start of the data from the > offset in the header. Each key stores its own offset, and its size. So > all LUKS implementations (including my class) would completely ignore > that extra block between the end of the key material and the start of > the data. Awesome! Unless this has any problematic side-effects, such as screwing things up for non-standard implementations, this should solve the problem. Thanks for looking into it! -- 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
Re: [rvl-list] Implement LUKS file format for Revelation
Erik Grinaker wrote: > On Sun, 2006-05-28 at 14:15 -0500, John Lenz wrote: >> Erik Grinaker wrote: >>> 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. >> The LUKS header does include a UUID to make each file/partition whatever >> unique. We might be able to do something with that... In any case, if >> you provide a password, we can open up the LUKS data part and check that >> the first few bytes are or whatever. We just won't be able >> to check before a password is inputed. > > Yeah, but I'm thinking more like a magic string to register in the fd.o > MIME database etc, so that nautilus will recognize it and Revelation > will be used to open the file. Actually, we can fix a location for a custom Revelation string. The way LUKS works is the LUKS header contains an offset where the raw data starts. Currently, this is calculated by finding the end of the key material, and rounding up to the nearest block size (size the start of the data needs to be aligned). We could insert an extra block after the key material, but before the first data block. The LUKS implementations would still work, because the format specifies that you look up the start of the data from the offset in the header. Each key stores its own offset, and its size. So all LUKS implementations (including my class) would completely ignore that extra block between the end of the key material and the start of the data. Actually, each key in the header also includes the offset the actual key material is is located at. So we could also insert a block between the LUKS header and the start of all the key material. Each block is 512 bytes, so there is more than enough space to store whatever data you want. Also, if we didn't want to insert blocks, we could store info between the end of the header or end of the key material and the end of the block they are in. (Since all these things round up to the nearest block, there is some leftover space). John
Re: [rvl-list] Implement LUKS file format for Revelation
On Sun, 2006-05-28 at 14:15 -0500, John Lenz wrote: > Erik Grinaker wrote: > > 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. > > The LUKS header does include a UUID to make each file/partition whatever > unique. We might be able to do something with that... In any case, if > you provide a password, we can open up the LUKS data part and check that > the first few bytes are or whatever. We just won't be able > to check before a password is inputed. Yeah, but I'm thinking more like a magic string to register in the fd.o MIME database etc, so that nautilus will recognize it and Revelation will be used to open the file. > > 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. > > Yeah, the latest patch on my server implements support for adding and > deleting a key, but just includes defaults for encryption settings and > the like. The only non-obvious entry is the number of iterations to use > for the key, which I am currently prompting for on the change key > dialog. I guess we could just choose a default of say 4000 or so (which > is what the textbox currently defaults to) Yeah, I think we should use a default for the key iterations. 4000 should be sufficient, but we might as well up it to 1. I'll consider support for adding/deleting keys, but I suspect not many people will have any use for this. Keep it simple, y'know. > > 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. > > > > Yeah, I have currently switched over to using revelation with my patch > and the LUKS format for all my passwords and revelation use. I have > even added a second key using the GUI. If you don't switch over, I > would like a preference or command option or something to use the LUKS > format as the default. There's a big probability that I'll use LUKS by default, but I need to play with it a bit first. -- 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
Re: [rvl-list] Implement LUKS file format for Revelation
Erik Grinaker wrote: > 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. The LUKS header does include a UUID to make each file/partition whatever unique. We might be able to do something with that... In any case, if you provide a password, we can open up the LUKS data part and check that the first few bytes are or whatever. We just won't be able to check before a password is inputed. > > 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. Yeah, the latest patch on my server implements support for adding and deleting a key, but just includes defaults for encryption settings and the like. The only non-obvious entry is the number of iterations to use for the key, which I am currently prompting for on the change key dialog. I guess we could just choose a default of say 4000 or so (which is what the textbox currently defaults to) http://www.cs.wisc.edu/~lenz/luks (I recently made some changes to the luks.py class, so you should redownload it...) > > 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. > Yeah, I have currently switched over to using revelation with my patch and the LUKS format for all my passwords and revelation use. I have even added a second key using the GUI. If you don't switch over, I would like a preference or command option or something to use the LUKS format as the default. John
Re: [rvl-list] Implement LUKS file format for Revelation
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:" because it is stronger and only > very slightly slower (only really noticeable when using the encryption > on a hard disk). > > La
Re: [rvl-list] Implement LUKS file format for Revelation
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:" 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
Re: [rvl-list] Implement LUKS file format for Revelation
On Mon, May 8, 2006 5:02 am, Erik Grinaker said: > Great stuff! I'm really busy with work these days, but I should have > time to look more closely at this in a week or so. > > A couple of questions (sorry if you anwered this below, I only had time > to skim it): what dependencies will this introduce, and how much > overhead is there in terms of filesize and cpu/memory requirements? > No dependencies besides python-crypto and the standard python library. As for performance, doing decryption and encryption I can't really tell any speed slowdown. I am sure you can probably measure it and whatnot, and see a small slowdown. I see statistics quoted for the linux kernel around 2-3 % slower, but any encryption algorithm (like the one Revelation currently uses) has the same slowdown. Creating the file initialy takes ~6-7 seconds, mostly because it needs to generate a lot of random numbers, and python-crypto implementation of Random is slow, to get close to true cryptographic randomness. reducing the number of stripes for the key would make it faster, but as I said in the previous email, you only need to generate the header once. So after the initial generation of 6-7 seconds, every other save is fast. As for memory, only the header will need to be cached, and the header is a few K (depends on how many stripes the key uses, which I defaulted to 1000, but could reduce for smaller memory footprint and slightly reduced security). John
Re: [rvl-list] Implement LUKS file format for Revelation
On Mon, May 8, 2006 8:05 am, Farkas Levente said: > 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. > > a few more technical question: > - did you use the same magic as in luks partition? Uh, I don't think LUKS has a partition number (that would be stored in the partition table). Instead, the first 4 bytes of a luks file or partition are "LUKS". The kernel only knows to check it as a LUKS partiton or file because you tell it to (in a script in /etc/init.d or /etc/cyrpttab or on the command line) > - if yes how can the system (kerenl, driver) know wether it's a luks > file or luks filesystem ie. it contains only a file or a filesystem? The kernel does not care what is in the data portion... Once the encryption is set up, the decrypted data section of the LUKS file is accessable from the /dev/mapper/ file. So the kernel does not enforce any restrictions on the data, whatever is there gets exported into that file. You can access this data directly, or you can point mount at that file, telling mount that there exists a filesystem in the /dev/mapper/. Then, another linkage is setup between /dev/mapper/ and wherever you mount the partition. So, the kernel only knows that there exists a filesystem there because you tell it, either on the command line or in /etc/fstab John
Re: [rvl-list] Implement LUKS file format for Revelation
On Mon, May 8, 2006 5:50 am, Farkas Levente said: > 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? Not yet, but I plan to try and propose it soon. > 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? No, I currently don't have access to a windows system. LUKS just specifies a data section that can contain anything at all. LUKS does not put any restrictions on whatever goes into the data section. Normally, when you use it through the linux kernel, you would create a filesystem in the data portion of the LUKS file, but even the linux kernel does not enforce that. Once you set up the encryption, you can just read directly from /dev/mapper/test ... so when testing my class, I can just less /dev/mapper/test and see the XML data stored in the data section directly. (What you would do if it had a filesystem is something like "mount /dev/mapper/test /mnt/test", which tells mount to read from /dev/mapper/test. So for this revelation format, I just put the XML data directly in the data portion, instead of a filesystem. John
Re: [rvl-list] Implement LUKS file format for Revelation
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. a few more technical question: - did you use the same magic as in luks partition? - if yes how can the system (kerenl, driver) know wether it's a luks file or luks filesystem ie. it contains only a file or a filesystem? -- Levente "Si vis pacem para bellum!"
Re: [rvl-list] Implement LUKS file format for Revelation
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) > >
Re: [rvl-list] Implement LUKS file format for Revelation
Great stuff! I'm really busy with work these days, but I should have time to look more closely at this in a week or so. A couple of questions (sorry if you anwered this below, I only had time to skim it): what dependencies will this introduce, and how much overhead is there in terms of filesize and cpu/memory requirements? On Mon, 2006-05-08 at 01:22 -0500, 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 secu
