I'm going to have to go with no. http://ideone.com/0hpVxd
The problem is that the fact that the bit's values are consistent to their location.
For example, the outermost bytes only mix with the outermost bytes and the innermost bytes only mix with the innermost bytes.
The only time that doesn't occur is when the "+1" happens to cause a carry to happen.
You can see from the example that the lower input values yield very easy to "reverse" numbers. If you know the input number was small, simply take the back half of the hash, and reverse the bit order.
With larger input values, the pattern isn't as apparent, but you can still tell that it's there.
My other major concern is how the algorithm would handle messages with length greater than 64 bits. Most hash algorithms use a compression function for this, but from the code below, there doesn't seem to be one. If your
Lastly, even if this algorithm had iteration and a compression function, the fact that the output length is only 64 bits is quite troubling. Even if you had compression and iteration functions, any input message longer than 64 bits would also have a "collision" message that's less than 64 bits. The digest length alone makes it 2^64 times less secure than MD5.
Sorry mate.
The problem is that the fact that the bit's values are consistent to their location.
For example, the outermost bytes only mix with the outermost bytes and the innermost bytes only mix with the innermost bytes.
The only time that doesn't occur is when the "+1" happens to cause a carry to happen.
You can see from the example that the lower input values yield very easy to "reverse" numbers. If you know the input number was small, simply take the back half of the hash, and reverse the bit order.
With larger input values, the pattern isn't as apparent, but you can still tell that it's there.
My other major concern is how the algorithm would handle messages with length greater than 64 bits. Most hash algorithms use a compression function for this, but from the code below, there doesn't seem to be one. If your
Lastly, even if this algorithm had iteration and a compression function, the fact that the output length is only 64 bits is quite troubling. Even if you had compression and iteration functions, any input message longer than 64 bits would also have a "collision" message that's less than 64 bits. The digest length alone makes it 2^64 times less secure than MD5.
Sorry mate.
Thank you very much for your constructive criticism - something not many people I know actually give.
The aim of some of the different methods that I have tried is to get something which is fast, but if unsecure can be doubled in rounds without slowing encryption to a crawl.
The current iteration of Isenberg also rotates the result of the first rotation by 45 degrees clockwise, XORs it with the first rotation, and rotates that by 45 degrees counterclockwise, and XORs with the second rotation.
Since 64 bit digest, as you pointed out, was too small, I guess the next logical step is something like SSE2, with 256 bit digest words.
The search continues, I guess.
EDIT: Tipped you for your answer.
Matthew:out
