Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyed hashes (SipHash) #265

Open
TotalKrill opened this issue Apr 13, 2022 · 1 comment
Open

Keyed hashes (SipHash) #265

TotalKrill opened this issue Apr 13, 2022 · 1 comment

Comments

@TotalKrill
Copy link

Basically, a widely used hash function ( at least internally in software ) is SipHash, which needs a key to be verified is missing from the codec table.

I have a use case that would require a hash-function that produces small digests ( ideally max 32bits ) for IoT usecases.

The recommended parameters are SipHash-2-4 for best performance, and SipHash-4-8 for conservative security. A few languages use Siphash-1-3. (from Wikipedia )

Is there anything that prohibits this from being added in multicodec? In this case I suppose it will not, but for my intended usecase, I suspect that maybe it will be problematic in for example multihash

@rvagg
Copy link
Member

rvagg commented Apr 19, 2022

Gee, this one's a bit of a stretch. In theory we should just be able to add all of the useful (or valid?) members of the SipHash family, but keyed hash functions face a utility problem for content addressing, which is the primary use of multihash in that you also need the key to do anything useful with it.

But, the multicodec table, nor the multihash "spec" (afaik) don't dictate how they are used or constraints of systems that may prohibit their use in conjunction with a key, so I suppose there shouldn't be anything preventing addition of keyed hash functions. Maybe a bit of finesse applied to the comment column would be appropriate; but ultimately it tends toward caveat emptor around here (if someone wants to make CIDs with SipHash and discovers they're less useful for sharing data, then they'll discover that fairly quickly I think!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@rvagg @TotalKrill and others