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,
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
what do you think about it?
Levente "Si vis pacem para bellum!"