5 ms·
this approach results in false positives
by preseinger 3y ago
this approach results in false positives
- xigoi 3y agoExtremely unlikely if you take enough bits from the hash.
- preseinger 3y ago"extremely unlikely" is still not the same as "impossible" hash(x) != x
- xigoi 3y agoAre you afraid to go out because you might get struck by lightning?
- preseinger 3y agoif you and I have accounts at the same bank, it's incredibly unlikely that my account number will hash to the same value as your account number are you OK with the bank using a hash of your account number to identify your account instead of the number itself? of course not -- any risk of collision, no matter how low, is unacceptable that's the baseline -- risk tolerance is zero you have to justify any increase of that risk on a case-by-case basis
- xigoi 3y agoYeah, because the consequences of accidentally blocking someone on social media are just as serious as the consequences of a bank confusing two accounts.
- sebzim4500 3y agoIf the hash is cryptographically secure and 128 bits I would be perfectly comfortable with them assuming uniqueness of it. To repeat that guy's question, do you avoid going outside in order to avoid freak lightning strikes?
- preseinger 3y agohash functions map infinite-cardinality input sets to finite-cardinality output sets definitionally, this means each output value maps to multiple input values -- which means uniqueness is, factually, not guaranteed it doesn't matter if the likelihood of collisions is 1-in-10, or 1-in-100000, or 1-in-1000000000000, or etc. -- if a collision is possible at all, then uniqueness is not guaranteed, and cannot be assumed as true
- deleted 3y ago[deleted]
- Dylan16807 3y agoYou can and should assume sufficiently likely things. It's a waste of time to worry about probabilities with enough zeroes. Especially because in the real world even a mathematically perfect system has a baseline failure rate. If the chance of hash collision is orders of magnitude lower than the baseline failure rate, then there is no downside to using that hash.
- preseinger 3y ago> It's a waste of time to worry about probabilities with enough zeroes. what? no. absolutely not. the "baseline failure rate" of a program with some input values X is zero. > in the real world even a mathematically perfect system has a baseline failure rate. what? no. absolutely not. x = 1 print(x) this is not a probabilistic program, there is no baseline failure rate above zero, the output must be "1", any other output means the program is incorrect this line of reasoning is absolutely invalid -- hash(x) != x
- piperswe 3y agoIf a cosmic ray flips that 1 to a 3, that will bring your failure rate above zero. No program is correct then.
- 3y ago
- jazzyjackson 3y ago> are you OK with the bank using a hash of your account number to identify your account instead of the number itself? Why not? Cryptographically, entropically, there's no difference between a call to "give me a uuid to throw on this new account" and "now crunch it through a sponge function and use that instead" Your uuid generator will probably check for uniqueness, or your database will enforce unique values, so there's a few places you would be alerted of the collision, but 2^256 is a very large number
- preseinger 3y agoyou misunderstand the scenario if we're talking about hash(x) == x then the hash function doesn't consult any central DB to compute a UUID or evaluate uniqueness or anything there is no UUID generator or DB involved
- jazzyjackson 3y ago[flagged]
- jeroenhd 3y agoAn absolutely minimal probability of false positives. The probability that you can find a hash collision that's also a valid username is even smaller. I don't think it's something you'd need to worry about.