Looks like 1.8 may still have some accuracy problems. Output of the Sapphire II hashes seem to be incorrect when compared to the authors test program (Michael Paul Johnson). Test program and Sapphire II hash are very old, so info may not be reliable. Also, author does not recommend using algo for hash bigger than 32 bytes (256 bits).
Code:
Sapphire II Hash of "Hello World"
bits Author
128 DE0BCBC20DC0D9A8757D9F5A872691BE
160 DE0BCBC20DC0D9A8757D9F5A872691BE3B1386F1
192 DE0BCBC20DC0D9A8757D9F5A872691BE3B1386F149454785
224 DE0BCBC20DC0D9A8757D9F5A872691BE3B1386F149454785F33EF56A
256 DE0BCBC20DC0D9A8757D9F5A872691BE3B1386F149454785F33EF56A04C2CE57
bits KGA1.8
128 CC5160EFFC89B049C7D98C621F40E962
160 9AB4E676C69D8D197A68FD91502B8C6BFEF7AE16
192 F594394418FD8F25842901D03584CD1927C8E267CDD5CB43
224 575A2E7589332F008514BC4BE7059F33AC7186734CDB4FC611F09322
256 7CE0CF43114C7F198098D08012E5E10BD0DE9E71B2C295607EBB094E3AAA1C4B
Source code of final hash generation is :
Code:
void sapphire::hash_final(unsigned char * hash, // Destination
unsigned char hashlength) // Size of hash.
{
int i;
for(i = 255; i >= 0; i--)
encrypt((unsigned char) i);
for(i = 0; i < hashlength; i++)
hash[i] = encrypt(0);
}
That last loop suggests to me that first N bytes of N+4 byte hash should indeed be the same.
Git