Date: Fri, 28 Dec 2007 18:32:21 -0800 From: Garrett Cooper <youshi10@u.washington.edu> To: Ivan Voras <ivoras@freebsd.org> Cc: hackers@freebsd.org Subject: Re: BSD license compatible hash algorithm? Message-ID: <1896C9EB-E6B3-4B7D-B354-7DE0774D685C@u.washington.edu> In-Reply-To: <fl2qiv$qoh$1@ger.gmane.org> References: <5950EE0C-383D-4D6B-9991-A0DEABD2ADE4@u.washington.edu> <20071228003716.GB48997@lor.one-eyed-alien.net> <B8D4C3C6-B867-4550-9F17-4DC6930D10E2@u.washington.edu> <fl2qiv$qoh$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1896C9EB-E6B3-4B7D-B354-7DE0774D685C>