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.

Reply via email to