How to generate human friendly product keys using asymmetric crypto?
-
I would like to generate human friendly product keys similar to what Microsoft and many others do. The keys should have the property of being 25 or 30 characters. I need to be able to generate many individual keys, on the order of 10000 or so probably. They should be generated in such a way that it is easy to verify that a particular key is one which I generated, but hard for someone else to generate the identical list of keys. I am aware of commerical products that do this, but it seems like something that wouldn't be that hard to reinvent. It appears to me that this requirement calls for use of an asymmetric crypto algorithm. Like all locks, this one is intended to help honest people stay honest. I'm not too worried about the hacker with a disassembler, but it ought to be at least challenging for him to generate a valid product key. Any suggestions, especially pointers to sample code, will be greatly appreciated. Jim
-
I would like to generate human friendly product keys similar to what Microsoft and many others do. The keys should have the property of being 25 or 30 characters. I need to be able to generate many individual keys, on the order of 10000 or so probably. They should be generated in such a way that it is easy to verify that a particular key is one which I generated, but hard for someone else to generate the identical list of keys. I am aware of commerical products that do this, but it seems like something that wouldn't be that hard to reinvent. It appears to me that this requirement calls for use of an asymmetric crypto algorithm. Like all locks, this one is intended to help honest people stay honest. I'm not too worried about the hacker with a disassembler, but it ought to be at least challenging for him to generate a valid product key. Any suggestions, especially pointers to sample code, will be greatly appreciated. Jim
this might work: assuming you're using RSA (or something similar): 1. come up with a public/private key pair. 2. put one of your keys in your app, and one in your license creator. 3. generate a series of short plaintext strings like this: "SomeText_######" , where ###### is an incrementing counter, or a time stamp, or some other unique value (just to ensure that no two codes are the same). the actual content doesn't matter to the algorithm, only that the form of the string can be verified when decoded. 4. encrypt each of those strings with your license creator key. then output them as hex strings: a0b4-d3ee-091c-etc. the code length will depend on how big the input data was. 5. distribute those keys to your users. 6. when your app gets a license code, decrypt it using the key from #2. 7. if the decrypted code matches the form from #3, it's a valid license code. take a look at crypto++[^]. Software | Cleek
-
this might work: assuming you're using RSA (or something similar): 1. come up with a public/private key pair. 2. put one of your keys in your app, and one in your license creator. 3. generate a series of short plaintext strings like this: "SomeText_######" , where ###### is an incrementing counter, or a time stamp, or some other unique value (just to ensure that no two codes are the same). the actual content doesn't matter to the algorithm, only that the form of the string can be verified when decoded. 4. encrypt each of those strings with your license creator key. then output them as hex strings: a0b4-d3ee-091c-etc. the code length will depend on how big the input data was. 5. distribute those keys to your users. 6. when your app gets a license code, decrypt it using the key from #2. 7. if the decrypted code matches the form from #3, it's a valid license code. take a look at crypto++[^]. Software | Cleek
That's a good idea, but I have a question about step #5, "distribute those keys to your users". I would like to have a fixed length key of no more than 30 characters, similar to what microsoft does. I'm not sure that's feasable if the key is just hex strings. I guess I don't grock the relationship between the lenght of the plantext and the lenght of the cyphertext. Perhaps I should encode the key with a base 26 system. I already incorporate parts of crypto++ in my app for symmetric encryption, it is an excellent product.
-
That's a good idea, but I have a question about step #5, "distribute those keys to your users". I would like to have a fixed length key of no more than 30 characters, similar to what microsoft does. I'm not sure that's feasable if the key is just hex strings. I guess I don't grock the relationship between the lenght of the plantext and the lenght of the cyphertext. Perhaps I should encode the key with a base 26 system. I already incorporate parts of crypto++ in my app for symmetric encryption, it is an excellent product.
Jim Howard wrote: I guess I don't grock the relationship between the lenght of the plantext and the lenght of the cyphertext. i believe RSA requires the block size to be the same as the key length. so, a 32 byte code string, based on 16 hex numbers, gives you a 128-bit key - not very big. Jim Howard wrote: Perhaps I should encode the key with a base 26 system or base32. it gives you an extra byte of data for every 8 code charaters vs base16. (8 chars b32 = 40 bits. 8 chars b16=32 bits) Software | Cleek