another interesting project which may be related is:

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!"

Reply via email to