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. > >
