Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 565
    • Issues 565
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 93
    • Merge requests 93
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source ProjectsISC Open Source Projects
  • BINDBIND
  • Issues
  • #360
Closed
Open
Issue created Jun 23, 2018 by Ghost User@ghost

Replace FNV-1a with SipHash

NOTE: This is a confidential ticket because it may describe a vulnerability.

I suggest replacing FNV-1a in BIND with SipHash: https://131002.net/siphash/siphash.pdf

BIND uses FNV-1a for the hashtables with a random starting seed (the offset basis).. but IMO it falls short of being a true universal hash function because I suspect it would map to different buckets based on the initial offset basis chosen, but colliding keys would still map to the same buckets regardless of the initial offset basis (the bucket# may be different).

SipHash is a more robust hash function and it suggests the hash table function as an application. The change to SipHash would be fairly easy, but note that some parts of BIND may perform incremental hashing (i.e., they add input data to compute the hash from different places of the library). So the hash function would need to follow an API similar to the HMAC contexts in BIND, OR, the data would have to be concatenated into a buffer as a whole before hashing.

I suspect collisions may be exploitable by hash flooding (there have also been previous reports of these). See section 7 of the siphash paper and references [13], etc. in the paper for details.

See this presentation: https://media.ccc.de/v/29c3-5152-en-hashflooding_dos_reloaded_h264

Edited Jun 23, 2018 by Ghost User
Assignee
Assign to
Time tracking