4 ms·
> I built something better that's actually secure and performant here That's quite a bold claim, isn't it? I also don't see how it's an alternative to OP consi
by rstarast 6y ago
> I built something better that's actually secure and performant here
That's quite a bold claim, isn't it? I also don't see how it's an alternative to OP considering it doesn't even mention how to integrate the code with any database, let alone Postgres.
As an aside, how does your approach deal with collisions? Why would the chance of collisions be any lower than with the random approach if you're using what seems to come down to a cryptographically secure hash function?
- bouk 6y agoThey're not using a hash function: https://en.wikipedia.org/wiki/Format-preserving_encryption https://en.wikipedia.org/wiki/Format-preserving_encryption
- gopalv 6y agoThere are reversible bit hash functions too. I've used twang's 64 bit mix in places where the domain is just as big as the hash space - 64 bit to 8 byte hash to 12 byte Y64 strings. That said, the results are almost always ugly, if I had to do it again, I'd do it the way gfycat does (adjective, adjective, animal).
- bouk 6y agoThanks for pointing me to the concept of bit mix functions, very interesting.
- boogerlad 6y agoTechnically, it can be integrated with Postgres with https://github.com/wasmerio/wasmer-postgres https://github.com/wasmerio/wasmer-postgres. That said, it makes little sense to integrate this at the database level since it'll bloat up the column size, unless just the encrypted integer is stored (without converting to a base58 string). As for collisions, a hash function maps an input of any length to an output of fixed length, so collisions will happen eventually. What I'm using is encryption, which cannot collide, otherwise decryption would be impossible https://crypto.stackexchange.com/questions/60473/can-collisions-occur-with-encryption-algorithms https://crypto.stackexchange.com/questions/60473/can-collisi...