4 ms·

"extremely unlikely" is still not the same as "impossible" hash(x) != x

• xigoi 3y ago
  Are you afraid to go out because you might get struck by lightning?
  • preseinger 3y ago
    if 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 ago
      Yeah, 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 ago
      If 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 ago
        hash 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 ago
          You 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 ago
              If a cosmic ray flips that 1 to a 3, that will bring your failure rate above zero. No program is correct then.
              • preseinger 3y ago
                i can't control solar rays i can control what my application uses as IDs
            • Dylan16807 3y ago
              > what? no. absolutely not. Please explain how the benefit outweighs the cost to spend even 30 seconds to prevent a potential problem with 10^-40 probability. (And by that I mean 10^-40 total probability, not per-item.) > 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 You could have a power outage, or the OS could crash, or the CPU could have a bug on those opcodes when certain counters roll over at the exact wrong time, or a bit could flip in your memory. The baseline failure rate for a program on a computer in the universe is never zero. This isn't abstract math. And the collision rate of many hashing systems is much smaller than that baseline failure rate. There are even situations where assuming a hash never collides can increase reliability, because the code will be done sooner and that improves the baseline.
    • 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 ago
        you 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]