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