If all you want is to obfuscate the fact that your social media site only has 200 users and 80 posts, simply use a permutation over the autoincrement primary key. E.g. IDEA or CAST-128, then encode in base64. If someone steps on your toes because somewhere in your codebase you're using a forbidden legacy cipher, just use AES-128. (This is sort of the degenerate/tautological base case of format-preserving encryption)
(What do you think Youtube video IDs are?)
I always thought they are used and stored as they are because the kind of transformation you mention seems terribly expensive given the YT's scale, and I don't see a clear benefit of adding any kind of obfuscation here.
> What do you think Youtube video IDs are?
I actually haven no idea. What are they?
(Also what is the format of their `si=...` thing?)
Why not use AES-128 by default? Your CPU has instructions to accelerate AES-128.
Can't you just change the starting value of your sequence?
The problem with this approach is that you now have to manage a secret key/secret for a (maybe) a very long time.
I shared this article a few weeks ago, discussing the problems with this kind of approach: https://notnotp.com/notes/do-not-encrypt-ids/
I believe it can make sense in some situations, but do you really want to implement such crypto-related complexity?