I know it's insecure, but I need to for number of profile;
I need a hash algorithm to provide less than 10 bytes.
That question is impossible to answer without understanding your requirement for the hash function.
Since we're in security.se, though, I suppose that you're asking for a secure hash function. In that case, I'm afraid the answer is: it can't be done.
You see, a hash function is just a mapper: it persistently maps data of arbitrary size to a fixed-length key. Nothing more. For instance, a function that takes a string and returns a constant number is a perfectly valid (if somewhat useless) hash function.
Now, a cryptographic hash functions are a class of hash functions that have additional properties. The ideal cryptographic hash function has the following properties:
- It is pre-image resistant: you can't easily find an input that will give you a specific output faster than brute-forcing in input space.
- It is second-preimage resistant: given a specific input, you can't easily find a second input that will give you the same output.
- Is resistant to collisions: You cannot easily find two messages that will result in the same output, even given a large number of different inputs.
All this more or less rely on the fact that, even if the key space is smaller than the input space, it is still too big to be exhaustively mapped. Otherwise, you could spend a lot of time writing a reverse-mapping table and then you'll have a simple way to break 1.
That is why you need to explain what properties you expect from a 10-byte hash function: the standard secure hash functions will not work for you while retaining their secure properties. That doesn't mean, however, you cannot use them if your requirements are different.
While I can't think of any reason as to why someone would restrict a hash to 10 bytes, if you really want to, I guess you can.
What you could do is something like this answer: What is the best 32bit hash function for short strings (tag names)? where you get the md5 of the string and then truncate it to 10 or however many bytes.
Honestly, unless if you can justify the reason as to why you would be doing something like this, just don't. Figure out a way to increase the allocated dataspace into something that can support a hash as large as bcrypt. It is the go to algorithm when generating secure hashes, even if it might seem hard to implement.
If you're using it for file or message integrity calculations you can use CRC32, or if you're inclined to use a cryptographic algorithm you could just take the bottom or top bytes of any hash algorithm output - it'll be consistently reproducible and mostly unique to the data you hashed, though you'll be looking at a higher rate of collisions.