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
On Wed, 2006-03-29 at 11:18 +0200, Farkas Levente wrote:
> 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.
> - 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:
> 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
> 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?