MD5P (Variable length hash, kindof)

After discovering MD5 and SHA-1 have been cracked (i.e. collisions
found quickly) I began wondering how to make them more secure, no doubt
many others have done.

I came across the idea of "Variable Length Hashing" which also isn't
new, but the idea was to me. Anyhow, this went against the definition
of a hashing function as it should provide a fixed length hash. I
decided this could be overcome by adding in blank (0 bit) after the
given length. After consideration about how to figure out how this
blank space should be calculated, how much blank space to have maximum
and indeed what to do with the junked data I came to the following
conclusions:

I would adapt the current MD5 implementation to my own end
8 - 16 bytes would be sufficient for free space
All the data in the message should be added (igoring overflow) modulo
128 to find the free space

This means that the collisions must add up to the same (modulo 128) to
create the same hash, making it harder to do.

After creating this blank space I decided to add all the bits I junked
to the unafected first 8 bytes of the hash. I would then take the
current data buffer, fill the beginning with the message sum and fill
the end with the current hash, then process this once more through the
standard MD5 algoithm so as not to have the 0 bits.

I belive that my attempts to make MD5 more secure have been successful,
but I would like some feedback from more experienced security
programmers/mathematicians to what my few lines of code will actually
do to the security of the algorithm.

My added lines are as follows (where MD5->s is the sum):

        memcpy(MD5->data, MD5->s, 4);
        MD5->s = MD5->s % 128;
        MD5->states[0] += MD5->states[2] & (0xFFFFFFFF >> MD5->s);
        MD5->states[1] += MD5->states[3] & (0xFFFFFFFF >> (MD5->s - 64));
        MD5->states[2] &= 0xFFFFFFFF << MD5->s;
        MD5->states[3] &= 0xFFFFFFFF << (MD5->s - 64);
    memcpy(MD5->data+47, MD5->states, 16);
        MD5_Process(MD5);

Obviously this does not make much sense without the surrounding code,
but I decided that would be too long to paste, if you would like it
please email me at aie9321 at gmail dot com.

I'd appreciate any feedback, thanks, Chris.
Received on Fri Dec 23 20:11:10 2005