I’m looking for an easy and reversible method of obfuscating integer IDs. Ideally, I’d want the resulting obfuscation to be at most eight characters in length and non-sequential, meaning that the obfuscation of “1” should look nothing like the obfuscation for “2” and so on.
This isn’t meant to be secure by any means, so this isn’t a huge concern. Additionally, the integers I’ll be obfuscating aren’t large – between one and 10,000 – but I don’t want any collisions, either.
Does anybody have any ideas for something that would fit this criteria?
I derived an idea from Pearson hashing which will work for arbitrary inputs as well, not just 32-bit integers. I don’t know if this is the exact same as Greg answer, but I couldn’t get at what he meant. But what I do know is that the memory requirements are constant here. No matter how big the input, this is still a reliable obfuscation/encryption trick.
For the record, this method is not hashing, and it does not have collisions. It’s a perfectly sound method of obfuscating a byte string.
What you need for this to work is a secret key
_encryptionTablewhich is a random permutation of the inclusive range 0..255. You use this to shuffle bytes around. To make it really hard to reverse it uses XOR to mix the byte string a bit.You can then use the BitConverter to go between values and byte arrays or some convert to base 64 or 32 to get a textual representation. Base 32 encoding can be URL friendly if that’s important. Decrypting is as simply as reversing the operation by computing the inverse of the
_encryptionTable.You can also do other fun things if you’re working on a 32-bit integer and only care about the numbers greater than or equal to 0 which makes it harder to guess an obfuscated number.
I also use a secret word to seed a pseudo number generator and use that to setup the initial permutation. That’s why I can simply get the value by knowing what secret word I used to create every thing.
This is somewhat secure, the biggest flaw here is that the encryption, XOR with 0, happens to be the identity of XOR and doesn’t change the value (
a ^ 0 == a). Thus the first encrypted byte represent the random position of that byte. To work around this you can pick a initial value forc, that is not constant, based of the secret key by just asking the PRNG (after init with seed) for a random byte. That way it’s immensely more difficult even with a large sample to crack the encryption as long as you can’t observe input and output.