As has been pointed out already, these schemes are essentially security by obscurity--i.e. not so good. In practice, the keep honest people honest, but can be circumvented by anyone who cares to spend the time and effort.

The usual approach is to take some unique information (serial number, licensee name and address, etc.), combine it with secret salt value(s) and hash and chop and mash and mix and boil and burn. When you finish you want to wind up with a nice registration code. You need to make up your own ledgerdemain. A good system will provide numbers that are hard to combine to recover the salt value. The secret salt must be stored in the file, so you'll probably want to hide it in your code somehow--do something like use the 8 bit xor sum of line 256 in your perl script rather than my $salt = 'SECRETSALT-WOOT'; .

Textfiles.org has some essays on cracking serial numbers, they may give you some ideas about how other systems work.

If you read the above sources, you'll see that even if you generate ultra-secure codes that cannot be guessed, someone can always decompile your software and reverse engineer your algorithms. If you want maximum achievable security, you'll have to write code that comes out obscured after it has been deparsed, or decompiled (or write obscured assembler). Of course this code can still be decontstructed by a dedicated cracker.

...these codes to be generated by and also validate with some sort of obscure algorithm.

Also note that obscurity isn't secure. See Secrets and Lies by Schneier (ISBN 0471453803).

First of all you should ask yourself why you want do this. And obviously answer that too ...

Too often people feel like protecting their work using serials and stuff like that just to realize they provide little or no protection at all. Consider what happens when someone manages to replicate you serial generation process (which will eventually happen as your application is more and more used by people), or more simply one of your clients puts his/her serial on the Net. ;-)

On the other hand you could issue PGP certificates signed with your secret key, and have your application check the certificate fingerprint for authenticity. Of course that doesn't stop anyone from distributing one of your certs ... but if you really want to do this there's nothing to stop you.

Keep in mind that your app is in the user's hands, so anyone with some time and knowledge can trick it into "thinking" any other certificate is the "right" one.

You might find The Case of Quake Cheats illuminating about what that means.

1) although random generation would be a headache (gets slower as it has to check more and more used codes), pseudo random generation can work because it covers each possibility once for a consecutive set of integers. But you want much larger primes than are used in the trivial linked example.

2) use a secret, obscure but consistent filter to remove the majority of generated codes and enable a validity test e.g. filter out anything that isn't a factor of a certain prime (not a suggestion -- too insecure -- but an indication of what such a filter is). The test should significantly reduce the candidate valid codes, so plenty of size is needed for each code to leave enough left over - 16 bytes is popular for codes which are matched against a validity list but more are needed for unmatched codes which rely on a validity algorithm, depending on the inclusion percentage of the filter you select, so that enough valid codes remain over a significant period of possible usage.

3) Two-way encryption is needed after that, because filtering after encryption is arguably too transparent and one-way encryption after filtering would prevent validity testing. GnuPG contains enough ammunition for this.