Claudio

2004-09-28 07:30:26 UTC

Hello,

This is a method for a hash function, based on a new technique (I

think it's new, but this should be validated).

#define UL unsigned long

#define LEFT 13

#define RIGHT 19

void round()

{

hash[4] += hash[0] >> RIGHT;

hash[0] += hash[0] << LEFT;

hash[0] += hash[1] >> RIGHT;

hash[1] += hash[1] << LEFT;

hash[1] += hash[2] >> RIGHT;

hash[2] += hash[2] << LEFT;

hash[2] += hash[3] >> RIGHT;

hash[3] += hash[3] << LEFT;

hash[3] += hash[4] >> RIGHT;

hash[4] += hash[4] << LEFT;

}

void processBlock(const UL in[25])

{

int i, j, r, s;

for (i = 0; i < 5; i++)

{

s = 0;

for (r=0; r<5; r++)

{

for (j = 0; j < 5; j++)

{

hash[j] ^= in[j+s];

hash[j]++;

}

round();

s += 5;

}

}

}

It processes blocks of 800 bits. The same block is processed 3 times.

Each time, a sub-block of 160 bits is XORed with the hash block, and the

result is mixed with itself (round() function), by making the 32 bits

integers overlap with themselves (overlapping, and then addition modulo

232).

Can anybody tell me whether this idea is completely bad or very

interesting ??

The facts:

- The avalanche effect seems OK after 5 rounds. This has been

empirically checked with the tests programs: ENT, NIST , DIEHARD (I

generated a set of hashvalues, from a given 800-bits block where a

32-bits integer at a given position was incremented before generating

the next hashvalue. I chosed the following integers: in[0] and in[24]).

- fast algorithm. In Assembly, the inner loop will take about 40 cycles

by using MMX instructions, and by storing the hash block in MMX

registers (6 cycles per DWORD processed). The processBlock() function

will therefore take about 40*5*5 = 1000 cycles, for 100 bytes => about

10 cycles / byte, which is just a little bit slower than MD5.

Thanks a lot in advance for your remarks (sorry for my non-perfect

english).

This is a method for a hash function, based on a new technique (I

think it's new, but this should be validated).

#define UL unsigned long

#define LEFT 13

#define RIGHT 19

void round()

{

hash[4] += hash[0] >> RIGHT;

hash[0] += hash[0] << LEFT;

hash[0] += hash[1] >> RIGHT;

hash[1] += hash[1] << LEFT;

hash[1] += hash[2] >> RIGHT;

hash[2] += hash[2] << LEFT;

hash[2] += hash[3] >> RIGHT;

hash[3] += hash[3] << LEFT;

hash[3] += hash[4] >> RIGHT;

hash[4] += hash[4] << LEFT;

}

void processBlock(const UL in[25])

{

int i, j, r, s;

for (i = 0; i < 5; i++)

{

s = 0;

for (r=0; r<5; r++)

{

for (j = 0; j < 5; j++)

{

hash[j] ^= in[j+s];

hash[j]++;

}

round();

s += 5;

}

}

}

It processes blocks of 800 bits. The same block is processed 3 times.

Each time, a sub-block of 160 bits is XORed with the hash block, and the

result is mixed with itself (round() function), by making the 32 bits

integers overlap with themselves (overlapping, and then addition modulo

232).

Can anybody tell me whether this idea is completely bad or very

interesting ??

The facts:

- The avalanche effect seems OK after 5 rounds. This has been

empirically checked with the tests programs: ENT, NIST , DIEHARD (I

generated a set of hashvalues, from a given 800-bits block where a

32-bits integer at a given position was incremented before generating

the next hashvalue. I chosed the following integers: in[0] and in[24]).

- fast algorithm. In Assembly, the inner loop will take about 40 cycles

by using MMX instructions, and by storing the hash block in MMX

registers (6 cycles per DWORD processed). The processBlock() function

will therefore take about 40*5*5 = 1000 cycles, for 100 bytes => about

10 cycles / byte, which is just a little bit slower than MD5.

Thanks a lot in advance for your remarks (sorry for my non-perfect

english).