BSD license compatible hash algorithm?

Garrett Cooper youshi10 at u.washington.edu
Fri Dec 28 18:32:19 PST 2007


On Dec 28, 2007, at 4:35 AM, Ivan Voras wrote:

> Garrett Cooper wrote:
>
>>     Looks promising, but how difficult would it be to port the  
>> code to other platforms (Win32 for instance?).
>
> The hash algorithm itself as implemented in hash.h is pretty much a  
> text-book hash algorithm (D.J.Bernstein's):
>
> #ifndef HASHINIT
> #define HASHINIT        5381
> #define HASHSTEP(x,c)   (((x << 5) + x) + (c))
> #endif
>
> /*
>  * Return a 32-bit hash of the given buffer.  The init
>  * value should be 0, or the previous hash value to extend
>  * the previous hash.
>  */
> static __inline uint32_t
> hash32_buf(const void *buf, size_t len, uint32_t hash)
> {
>         const unsigned char *p = buf;
>
>         while (len--)
>                 hash = HASHSTEP(hash, *p++);
>
>         return hash;
> }
>
> It apparently has some weaknesses if used on binary (non-text) data  
> but I don't see why it wouldn't work on Windows.

Well, when I mentioned 'difficulty to port to Windows', I was  
referring to the number of references that the API may have to

This algorithm would be used for storage, but I could see potential  
for needing improved security, as someone changing the pkg db in  
memory could yield unwanted pkg installations or deletions, and just  
unwanted pkg behavior in general from occurring thanks to some  
malicious users..

Anyhow, thanks for the ideas I really do appreciate it. Overall, I  
think I will stick with BDB's hash(3) (seems less data collision  
prone, as was pointed out earlier, and less of a security risk) as I  
wasn't aware of the NULL argument, no filename 'clause' with dbopen(3).

-Garrett


More information about the freebsd-hackers mailing list