Skip to content

feat: allow caller-provided SipHash keys#30

Merged
lidel merged 7 commits intomasterfrom
feat/custom-siphash-keys
Mar 13, 2026
Merged

feat: allow caller-provided SipHash keys#30
lidel merged 7 commits intomasterfrom
feat/custom-siphash-keys

Conversation

@lidel
Copy link
Copy Markdown
Member

@lidel lidel commented Mar 4, 2026

the siphash keys were hardcoded as 0xdeadbeaf and 0xfaebdaed. anyone can read these from the source and craft inputs that hash to the same bit positions, filling the filter faster and raising false positives.

add NewWithKeys(k0, k1, ...) so callers can supply their own random keys (e.g. generated once per node). this restores the collision resistance that siphash is designed to provide.

  • sipHash.go: extract siphash constants and default keys, read k0/k1 from the Bloom struct instead of using hardcoded values
  • bbloom.go: add k0/k1 fields, add NewWithKeys constructor, persist custom keys in JSON (omitted when using defaults)
  • bbloom_test.go: tests for custom keys, JSON round-trip with custom keys, default keys omitted from JSON
  • doc.go: mention NewWithKeys for untrusted data

This was originally flagged by @Artoria2e5 in #11

the siphash keys were hardcoded as 0xdeadbeaf and 0xfaebdaed.
anyone can read these from the source and craft inputs that hash
to the same bit positions, filling the filter faster and raising
false positives.

add NewWithKeys(k0, k1, ...) so callers can supply their own
random keys (e.g. generated once per node). this restores the
collision resistance that siphash is designed to provide.

- sipHash.go: extract siphash constants and default keys, read
  k0/k1 from the Bloom struct instead of using hardcoded values
- bbloom.go: add k0/k1 fields, add NewWithKeys constructor,
  persist custom keys in JSON (omitted when using defaults)
- bbloom_test.go: tests for custom keys, JSON round-trip with
  custom keys, default keys omitted from JSON
- doc.go: mention NewWithKeys for untrusted data
lidel added 6 commits March 13, 2026 14:25
resolve conflicts to incorporate both the hashVersion field
from #29 and the custom siphash keys from #30
marshal() was storing pointers to bl.k0/bl.k1 in the export struct.
In JSONMarshalTS, json.Marshal dereferences these pointers outside the
read lock, creating a potential data race.
- use it in JSONUnmarshal, requiring both K0 and K1 to be present
marshal() always writes both keys or neither, but hand-edited or
corrupted JSON could contain only one. silently falling back to
default keys in that case would produce a filter that cannot find
its own entries. error early instead.
callers treating keys as secret should know they are included
verbatim in the serialized filter.
@lidel lidel merged commit e882fc3 into master Mar 13, 2026
9 checks passed
@lidel lidel deleted the feat/custom-siphash-keys branch March 13, 2026 13:49
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

Successfully merging this pull request may close these issues.

1 participant