0

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.

Unique_Key
  • 69
  • 6

1 Answers1

0

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
timoh
  • 211
  • 1
  • 4
  • I understand your solution, but I'm not completely convinced: can I really get away with not carrying actual information inside the key, and simply use it as PK? I mostly wanted to encrypt a message within the key itself to make sure that it's a valid key, for example a short passphrase. – Unique_Key Sep 05 '12 at 10:48
  • The activation key contains the needed information (only your system and your client knows it). It is sort of a "password". If you use it as a PK it would guarantee it is unigue, but I would not make it PK initially, since other problems could arise. Of course depending on your system. But anyway, from your initial post, it looks like you could go with "random actication keys". – timoh Sep 05 '12 at 11:05
  • Alright, I will give this a shot; hopefully it will suffice, let's see. Thanks. – Unique_Key Sep 06 '12 at 13:38