I want to generate serial number alphanumeric of 8 digits. But i also want to hide/encrypt the number so no one can judge next number. And also i want to keep the length after encryption or sum shuffling mechanism.
For example my series like this: 1000002A 1000002B 1000002C
Any idea?
you can take md5 of your number, but you would better to generate purely random series and store them somewhere, in DB may be.
Please note that MD5 is not encryption but hashing, it calculates fixed length byte sequence (16) from string of any length. This is one way process you can never calculate initial string based on MD5 result.
Edit: People recommend SHA-2, another hash function: http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256cryptoserviceprovider.aspx
Edit: To prevent brute force attack you should add salt to your string and then apply hash function. sample: calculate hash from hash("1000002A" + "00523422E8AB604F90C80D43C5F6C0F6")
You may add a random string only you know to the number and hash both together. This makes it impossible for others to find out the next number. If you'd just hash the serial number, as soon as someone learns about it, he can try out the numbers until he gets the correct hash and could then find out the next number.
However I'd also recommend to just create a random value. If you loose your secret string all number->hash pairs are 'cracked'.
If you just want to use this serial number as an identifier, you could use random UUIDs. They're 128-bit long, so 32 significant characters in hexadecimal (plus hyphens if you need).
If the ordering of the sequence matters on your side, but not for the public side, you could store the UUID <-> sequence number correspondence in a database.
If size is an issue, you'll find that MD5 hashes are also 128-bit long and that SHA-1 hashes are 160-bit long. I'm not sure how truncating such a hash or UUID affects the randomness. It certainly increases the probabilities of collisions, but there might also be side-effects regarding the entropy.
EDIT: Further comments about size, since it's an important requirement for this question.
If you need the output to be at most 8 characters [0-9A-Z], that's 36^8 possible values. Since 2^41 < 36^8 < 2^42, you'd want a result to use 41 bits at most.
You could use a stream cipher or block cipher of 41 bits (perhaps in combination with a public key algorithm), where you'd be the only one to know the (shared) key. That's probably fine, but you'd need to be careful not to let examples plain text out, since that would probably be quite easy to attack. I don't know enough to give you more precise advice on the secure key-length, but if you look at the comparison of stream ciphers (assuming the information on Wikipedia is accurate), few seem to be under 80 bits and not be attackable in a relatively short time. Similarly, the entry about block ciphers says "As of 2006, 80 bits is normally taken as the minimum key length needed to prevent brute force attacks."
This document might also be of interest: "How to Calculate the Size of Encrypted Data?".
Essentially, it depends on what you mean by "no one can judge next number". I think you may get a degree of obfuscation with such a short length, but that probably wouldn't resist serious attackers, especially since knowing the fact it's a sequence might be helpful to them.