hi, another interesting project which may be related is: http://ecryptfs.sourceforge.net/ yours.
Erik Grinaker wrote: > Hi Farkas, > > I just wanted to apologize for not replying to your (very good) > suggestions yet. I am extremely busy with work and school these days, > and probably won't have time to work on Revelation for another month or > so. I'll give you a proper reply once I can sit down and focus for a > moment :) > > > On Wed, 2006-03-29 at 11:18 +0200, Farkas Levente wrote: >> hi, >> i read the encryption part of the proposed new file format and think a >> little bit about it. my first impression why wanna reinvent the wheel. >> there are many similar project and we should have to learn from it's >> faults, bugs etc... >> >> - my first impression that the header part is too short and has fixed >> length which is always turn out a problem later (no space extension). >> most of such project used to have a payload-offset so nothing have to be >> fixed (even 2 bytes can be enough in this case but imho 4 would be better). >> >> - why you want to fix so many things like: compression, encryption >> algorithm, hashing function, salt size, iv size, numer of iteration etc. >> even if there are many possibility for thses things it doesn't mean you >> have to support all kind of combinations! let me go through this one by one. >> >> - compression. why bzip2? ok i know this is currently the best but does >> it realy metter? and at the same time gzip is supported by most of the >> devel enviroment by default (like java, python etc) at the same time >> bzip2 is not. think about may be it'll the file format of the future:-) >> and at the same time since these are auto detectable from magic it can >> be detected too. >> >> - encryption algorithm, it can be configurable also the hash function. >> etc,etc... >> so >> - use a payload-offset header field. >> - use a configurable compression algorithm (gzip, bzip2, compress, zip, >> none, etc) compression-type header field. and the default be bzip. >> - use a configurable encryption algorithm, ie. cipher-name field, >> cipher-mode field. >> >> after that luks come into my mind: >> http://luks.endorphin.org/ >> it's well known getting the de facto ecryption standard on linux and can >> be used on windows with FreeOTFE. so why don't we simple use it? it's >> format: >> http://luks.endorphin.org/LUKS-on-disk-format.pdf >> can be perfect for us. the PHDR can be totaly the same. what's more it >> has many addon feature what can be used. eg. more password on a helpdesk >> there can be a passwordsafe and all sysadm has it's own password for the >> safe. if one of them leave the company that given password can be >> deleted, etc. what's more we don't have to develop any new crypto lib, >> which is always dangerous and can lead to different errors. so simple >> define the xml format (think about my previous suggestions) and put it >> into a luks file (ie. the bulk part of the luks file may be in a >> compressed form). and the gui can use any kind of xml source, luks file, >> compressed xml, non-compressed xml (can be placed on a encrypted >> filesytem where the extra encryption has no addon value). >> in this case we can separate: >> - encryption layer >> - compression layer >> - xml file format >> - gui >> what do you think about it? >> yours. >> >> > -- Levente "Si vis pacem para bellum!"
