You could but you would lose the performance benefits you were seeking by encoding information into the ID. But you could also use a randomized, proprietary base64 alphabet rather than properly encrypting the ID.

▲

pdpi 7 hours ago | parent | next [-]

XOR encryption is cheap and effective. Make the key the static string "IfYouCanReadThisYourCodeWillBreak" or something akin to that. That way, the key itself will serve as a final warning when (not if) the key gets cracked.

▲

Retr0id 7 hours ago | parent | next [-]

Any symmetric encryption is ~free compared to the cost of a network request or db query.

In this particular instance, Speck would be ideal since it supports a 96-bit block size https://en.wikipedia.org/wiki/Speck_(cipher)

▲

pdpi 7 hours ago | parent [-]

Symmetric encryption is computationally ~free, but most of them are conceptually complex. The purpose of encryption here isn't security, it's obfuscation in the service of dissuading people from depending on something they shouldn't, so using the absolutely simplest thing that could possibly work is a positive.

	▲	Retr0id 6 hours ago \| parent [-]
		XOR with fixed key is trivially figure-out-able, defeating the purpose. Speck is simple enough that a working implementation is included within the wikipedia article, and most LLMs can oneshot it.

▲

maxbond 7 hours ago | parent | prev [-]

A cryptographer may quibble and call that an encoding but I agree.

▲

pdpi 7 hours ago | parent [-]

A cryptographer would say that XOR ciphers are a fundamental cryptography primitive, and e.g. the basic building blocks for one-time pads.

	▲	maxbond 7 hours ago \| parent [-]
		Yes, XOR is a real and fundamental primitive in cryptography, but a cryptographer may view the scheme you described as violating Kerckhoffs's second principle of "secrecy in key only" (sometimes phrased, "if you don't pass in a key, it is encoding and not encryption"). You could view your obscure phrase as a key, or you could view it as a constant in a proprietary, obscure algorithm (which would make it an encoding). There's room for interpretation there. Note that this is not a one-time pad because we are using the same key material many times. But this is somewhat pedantic on my part, it's a distinction without a difference in this specific case where we don't actually need secrecy. (In most other cases there would be an important difference.)

▲

haileys 8 hours ago | parent | prev [-]

Encoding a type name into an ID is never really something I've viewed as being about performance. Think of it more like an area code, it's an essential part of the identifier that tells you how to interpret the rest of it.

	▲	maxbond 8 hours ago \| parent [-]
		That's fair, and you could definitely put a prefix and a UUID (or whatever), I failed to consider that.