WizCrypt07 FileFormat

I have been developing/using WizCrypt (http://wizcrypt.wiztools.org/)
for file encryption. This software developed as a need of mine for a
cross-platform software that would run on Java. Recently I decided to
`upgrade' its file-format from simple dump of encrypted stream to a
more meaningful format. The result is the `WizCrypt07' format:

http://svn.berlios.de/wsvn/wizcrypt/trunk/src/site/resources /spec/wizcrypt07-file-format.txt?op=file

Requesting valuable comments on this.

Subhash.

Re: WizCrypt07 FileFormat

"subwiz@gmail.com" (07-02-20 05:13:52):

> http://svn.berlios.de/wsvn/wizcrypt/trunk/src/site/resources /spec/wizcrypt07-file-format.txt?op=file
>
> Requesting valuable comments on this.

I see a number of design flaws in this format. One unimportant one:
You don't need such a long magic field. You don't need a 2^80 assurance
that the file is really a WizCrypt07 file. Four bytes should suffice
(2^32 assurance).

Secondly, there is no reason to compress the hash value of the key,
because it can't be compressed anyway, assuming that the hash function
in use is secure, which brings us to the next thing: MD5 is not
considered too strong anymore. While still suitable for existing
systems, it shouldn't be used in new systems. Use one of the larger SHA
functions, like SHA-256 or SHA-384, or even SHA-512.

Then, you really don't need a length field for the name of the
algorithm, and there is again no reason to compress this. Reserve at
most four bytes for the name, and two bytes each for both the block
length (which is variable in some algorithms) and the key length in
bits.

Last, but not least, save the length of the compressed data, which
should begin at a four- or eight-byte boundary in the file (for
performance reasons).


Regards,
E.S.

Re: WizCrypt07 FileFormat

Thanks for the valuable suggestions. My action points:

* I will change the magic number to `WC07' (how do I check if this
magic number is already taken by some other format? For my part, I
checked with the Linux `file' command.)
* Headers (like hash of password) will be moved out of compressed
data.
* Just now verified: Java 6's default JCE provider supports SHA-256.
Hash will be computed using this algorithm.

My doubts:

* Why do u say that I have to save the key length in the file? I just
save the hash of the key, when the user decrypts, I compute the hash
of the user provided key with what is saved in the file. If it does
not match, it is wrong. I do not see any reason for saving the key
length (it could be due to my ignorance).


Finally:


Last, but not least, save the length of the compressed data, which
should begin at a four- or eight-byte boundary in the file (for
performance reasons).


1. What advantage do I gain by having the length of the compressed
data saved in the file?
2. "four- or eight-byte boundary in the file" - does this mean
beginning 4 or 8 bytes in the file, or multiple of this in the file?
Again, I might be glaringly displaying my ignorance in this area, but
can u explain (or point to literature which explains) why this scheme
will improve performance.

Thanks
Subhash.

On Feb 20, 5:03 pm, Ertugrul Soeylemez wrote:
> "sub...@gmail.com" (07-02-20 05:13:52):
>
> >http://svn.berlios.de/wsvn/wizcrypt/trunk/src/site/resource s/spec/wiz...
>
> > Requesting valuable comments on this.
>
> I see a number of design flaws in this format. One unimportant one:
> You don't need such a long magic field. You don't need a 2^80 assurance
> that the file is really a WizCrypt07 file. Four bytes should suffice
> (2^32 assurance).
>
> Secondly, there is no reason to compress the hash value of the key,
> because it can't be compressed anyway, assuming that the hash function
> in use is secure, which brings us to the next thing: MD5 is not
> considered too strong anymore. While still suitable for existing
> systems, it shouldn't be used in new systems. Use one of the larger SHA
> functions, like SHA-256 or SHA-384, or even SHA-512.
>
> Then, you really don't need a length field for the name of the
> algorithm, and there is again no reason to compress this. Reserve at
> most four bytes for the name, and two bytes each for both the block
> length (which is variable in some algorithms) and the key length in
> bits.
>
> Last, but not least, save the length of the compressed data, which
> should begin at a four- or eight-byte boundary in the file (for
> performance reasons).
>
> Regards,
> E.S.

Re: WizCrypt07 FileFormat

"subwiz@gmail.com" (07-02-20 10:40:14):

> * I will change the magic number to `WC07' (how do I check if this
> magic number is already taken by some other format? For my part, I
> checked with the Linux `file' command.)

You don't, as magic fields aren't standardized or agreed on. In fact
it's best to use some random number. But the possibility of confusion
is pretty low anyway.


> * Why do u say that I have to save the key length in the file? I just
> save the hash of the key, when the user decrypts, I compute the hash
> of the user provided key with what is saved in the file. If it does
> not match, it is wrong. I do not see any reason for saving the key
> length (it could be due to my ignorance).

Don't confuse key length with passphrase length. You sure have some
secure means of converting the passphrase to a key, which is of fixed
length. Hash functions are suitable for this task. Since ciphers
support different key lengths, you need to store this length.

For example, AES supports key with 128 bits and 256 bits. Blowfish has
an even wider range of supported key lengths. And some ciphers may have
variable block lengths, too.

You should really read a few good books on cryptography, before you
start, because many cryptosystems fail because of their concept or
implementation, which comes from poor understanding of the designers.


> > Last, but not least, save the length of the compressed data, which
> > should begin at a four- or eight-byte boundary in the file (for
> > performance reasons).
>
> 1. What advantage do I gain by having the length of the compressed
> data saved in the file?

Checking whether the data has been transmitted completely. You have to
compress the data first before encrypting (otherwise compression is
worthless), so without a length field, you have no way to make sure the
data has been transmitted completely. It would be best to save the
length together with a CRC32 value (of the ciphertext).


> 2. "four- or eight-byte boundary in the file" - does this mean
> beginning 4 or 8 bytes in the file, or multiple of this in the file?

Multiples of this. Suppose the header takes 13 bytes. Then you begin
the encrypted data at byte 16 and leave the three sparse bytes empty.
In such a case (which doesn't happen normally), you may want to use this
space for extra information, like a CRC24 hash of the header (in case of
three bytes).


> Again, I might be glaringly displaying my ignorance in this area, but
> can u explain (or point to literature which explains) why this scheme
> will improve performance.

Because current computers can access data at 32 bit or 64 bit boundaries
much easier. The addressing takes less computation. But I guess, the
difference will be neglible for Java implementations anyway.


Regards,
E.S.