views:

2118

answers:

8

I wondering about how serial number generators and validator work. My aim would be to generate a serial number with five parts consisting of numbers and letters only.

I enjoy coding as a hobby and would not call myself a professional programmer. However, I am very interested in how those interesting functions work technically to broaden my mind.

Any hints, experiences or written algorithms are appreciated.

+1  A: 

Using my Google-Foo, I came up with this article:

http://www.mactech.com/articles/mactech/Vol.13/13.02/SerialNumberGenerator/index.html

Gavin Miller
+10  A: 

Well, traditionally serial numbers are serial ... numbers. So the first example off the production line has sn 0001 then the next one is 0002 and the next one is 0003. I think that most people can work out that algorithm.

I think you're actually asking about product keys, which use a similar mechanism to public key message signing - the product key is the encrypted value, the program has a public key which allows it to verify that the key is valid, but only the software vendor has the secret key to 'sign' the product key. The wikipedia article on digital signatures has the general mechanism; the only proviso is that for a key to be entered by the user it has to be quite a bit shorter than a PGP one.

If you are restricted to a very short serial number, then it's unlikely to be big enough to store the result of a typical signing mechanism, in which case it's quite common to just use some variant of checksum on it. That has the disadvantage of being easy to reverse engineer - it's security is because the algorithm is 'secret' rather than due to any cryptographic properties. Each product would have its own algorithm, and they usually get cracked quite quickly.

If you have 5 blocks of 5 characters, you have 36^25 combinations, which is bigger than 2^128, so could use one of the standard digital signature algorithms which generates a 128 bit, then convert that value to base 36.

Pete Kirkham
+9  A: 

Get yourself a public/private key pair. Generate sequence numbers (10000, 20000, 30000, 40000, ....) that have some identifying characteristic (e.g divisible by 10000). Encrypt that number using your private key. Encode that value using some human readable system (base 32 or 64) and separate the values into groups to make it easier for people to parse. Distribute the encoded serial number with each sale of you app.

Somewhere in the app, you have the public key hidden away. When a user enters an encoded serial number, first decode it back to binary. Use the public key to decrypt it. Check that it is divisible by 10000.

The hard part is in the implementation - hiding the public key in the app so that it can't be replaced easily. Choosing some sequence that you can identify easily, but not run out of values. Obfuscating the app so that someone can't easily skip past the whole check. etc...

Eclipse
Well, if you are able to decrypt it, it's already a guarantee that it was digitally signed by your private key, so it does not really matter what the content is, if your decryption algorithm is able to figure out correct decryption.
Stefano Borini
Most decryption techniques will let you run any value through the decryption algorithm. For most random input, you'll just get random output. With many algorithms, given a chunk of random data, there is a key that will decrypt that string to any other string.
Eclipse
+3  A: 

Whatever you do, try to make the left-most digit non-zero so the "codes" aren't interpreted as numbers and allowed to disappear when imported into Excel and other formats. I've found that's one of the biggest problems in my industry where we use them a lot. We've learned to start all serial numbers with a 1.

I think there was a video game recently that released bad serial numbers and they may have run into a problem like this.

Joe Philllips
your comment is very interesting, even if not a real answer to the question.
Stefano Borini
+1  A: 

You can use a random number generator and store the outputs in a database. In case of activation request, you just check if the serial is in the database and mark the serial as "used".

Of course, this needs an internet connection, but is good against "buy once, use many,many times" method and in case of support-call, you can reactivate that serial for another reinstall.

Later edit: You also must use for the internet verification an encrypted and authenticated connection, like a HTTPS one.

adrians
+9  A: 

Brandon Staggs wrote a good article on Implementing a Partial Serial Number Verification System. The examples are written in Delphi, but could be converted to other languages.

stukelly
+1  A: 

A GUID ("Globally Unique Identifier") could be an easy way to solve this:

http://en.wikipedia.org/wiki/Globally_Unique_Identifier

Guids contain 16 bytes and are most commonly written in text as a sequence of hexadecimal digits such as:

3F2504E0-4F89-11D3-9A0C-0305E82C3301

And most programming languages should be able to generate a GUID with one of the available libraries.

mjustin
Downvoted, because GUIDs are not "randomly" generated. They are guaranteed to be unique - not random, and therefore are not suitable for use as serial numbers.
amdfan
The word 'random' does not appear in the specification. 'Serial' however does, and this is even the opposite of random. So what is your reason for downvoting?
mjustin
The first digit in the third group, in the example '1', would indicate the algorithm used. Version 1 would contain the MAC-address of the generating entity, while version 4 is based on a pseudo-random number.
Simon Svensson