How to create a serial key-based activation mechanism, and what data to store on the DB?

Question

I am currently in the process of figuring out how to create a serial key-based activation mechanism for a web-based product management platform (the language doesn't matter as this is more of a design question than anything), in which every product sold has a license key to register for online support.

I have a serial key encoder/decoder class in place, which generates AES-encrypted data which is then base32 encoded to return a human-readable key; I need to figure out what to encrypt in there, if it should hold the actual product code or what.

Also, the encoder is generating a different decryption key for each serial as well, but I'm not sure if I like this approach. Which would be best between this and, say, using a salt for each key? Also, where should I store the decryption keys and salts? I'm thinking on the DB, along with the activation keys, for the salts or for the decryption keys in case the current approach is valid, is this correct?

I also have a requirement to keep the key length at bay, which means I can't pass a certain number of characters in my encryption. Should the activation key hold actual product data, or just point to a matching row on the DB where the activation key acts as PK and read everything I need from there?

Thanks in advance for your response, I hope my question isn't too sketchy; please bear with me as I am relatively new to this particular topic. I have read the other questions, but none seems to tackle the problem of actually storing the activation keys in a web-based environment.

Answer 1

It looks to me that there is no need for encryption at all.

You could create strong random bytes (say, using /dev/urandom) and use that as an activation key.

Something like 64 bits of randomness (read 8 bytes from urandom) is probably enough, as it gives you about 2^32 "activation keys" without collisions. Of course, make sure it is appropriate for your specific situation.

Your activation key could look, for example, like this (hex-encoded and spliced with "-"):

28d7-59bf-0a29-b482