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:

<snip>
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).
</snip>

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 <use...@xxxxxxxxxxxxxx> wrote:
"sub...@xxxxxxxxx" <sub...@xxxxxxxxx> (07-02-20 05:13:52):

http://svn.berlios.de/wsvn/wizcrypt/trunk/src/site/resources/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.


.

Relevant Pages

  • Magic Compression? (Why wont this work) (Code provided)
    ... I entirely accept the premise that there is no way to compress all ... or whatever hash you prefer) to the hash of the original file. ... the requisite number of digits. ... echo ""> file ...
    (comp.compression)
  • Re: Loop over keys and values of a hashtable
    ... The thing is, hash tables are by nature unordered, so no ... and then you rely on vendor promises. ... In fact, better, since the standard cannot promise a single ... > For this reason I think it would almost be more helpful for the ...
    (comp.lang.lisp)
  • Re: Loop over keys and values of a hashtable
    ... The thing is, hash tables are by nature unordered, so no ... >> even if you iterate over the same hash table you shouldn't expect to ... >> For this reason I think it would almost be more helpful for the ... a new loop term was added to specifically return the key and value like ...
    (comp.lang.lisp)
  • Re: WizCrypt07 FileFormat
    ... as magic fields aren't standardized or agreed on. ... save the hash of the key, when the user decrypts, I compute the hash ... support different key lengths, you need to store this length. ... compress the data first before encrypting (otherwise compression is ...
    (comp.security.misc)
  • Re: [patch 1/1] uml-update-2.6.8-finish
    ... if that is the reason it's ok. ... However, for the future, hashing is lower-O than rb-trees (if the hash ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)