4 ms·
>Re-encoding them and/or truncating them is as hard and error prone as just generating the randoms yourself. Feed the whole thing into sha256 and take the last
by hueving 11y ago
>Re-encoding them and/or truncating them is as hard and error prone as just generating the randoms yourself.
Feed the whole thing into sha256 and take the last X bytes where X is the amount you need for your shortener. If you can show that the last X bytes of sha256 have a chance for collision due to input, there is a lot of money in it for you. One of the nice things about a cryptographic hash is that all of the output has to be completely unpredictable based on the input.
- deleted 11y ago[deleted]
- mmalone 11y agoExactly, it's as hard and error prone as generating the randoms yourself. The solution you described requires an analysis of the hash function to determine collision probability, diligence to find a sha-256 implementation (circa a few years ago), review of said implementation, another analysis to figure out your truncation, then a proper implementation resulting in ~the same amount of code, except this time slower and with less entropy.
- michaelmior 11y ago> with less entropy What makes you believe this is the case?
- mmalone 11y agoYou're generating a random number (the UUID) then you're hashing it. It can't possibly have more entropy, and there's a chance two inputs to the hash will collide thus reducing entropy. Hashing a counter is actually a variety of CSPRNG. Basically you're re-seeding a hash-based PRNG with whatever PRNG the UUID code uses at each run. It's well known that an PRNG cannot have more entropy than its seed. Hence, it will at best have the same entropy, and probably have slightly less.