alecthomas / alecthomas/mph

Best ways to handle failure to find a collision-free hash

Đang mở
#6 4 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Go
Star
192
Fork
21
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

(I apologize if this is out of scope for this library, and for my relatively shallow understanding of MPHs.)

Using the FNV hash func and even some simple inputs (e.g., keys `c` and `c2`, where `c` is any character), the builder often fails to find a collision-free hash. This is not a limitation of this particular project; implementations of the same algorithm in other languages also frequently fail on this class of inputs. (I say "often" and "frequently" because the random seed is the current time, and sometimes it succeeds.)

Is there a generally accepted solution for handling this occurrence, such as retrying the generation with a different random seed? Or allowing a small number of collisions (and iterating over the collisions in Get) if the cardinality is small? (It might make the most sense to add support for these things in external code, not in this core mph lib. But I notice that gperf supports producing imperfect hashes, so there is some precedent for including them.)

So, basically, how do other people handle the failure to find a collision-free hash in their own code? (Just fall back to a map or another hashing scheme?)

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.