# Hash algorithm that provides less than 10 bytes

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:

1. 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.
2. It is second-preimage resistant: given a specific input, you can't easily find a second input that will give you the same output.
3. 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.

• Sorry, I don't understant how point 2 is different from point 3 – Tloz Jan 20 '16 at 15:12
• Point 2 means you can't find a second input that will result in the same output as a chosen plaintext. Point 3 means that, statistically, all outputs will be different (it's resistant to birthday attacks) – Stephane Jan 20 '16 at 15:15

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.

• You should remove the mention to BCrypt: it isn't a hash function, it's a password-based key derivation function (PBKDF). While they share some properties, they do not have the same application scope (you can't use a PBKDF for building a hash table, for instance) – Stephane Jan 20 '16 at 10:01
• Both bcrypt and PBKDF2 are ugly in terms of cracks per second, which is why I mentioned bcrypyt (generally slower rates than pbkdf2). I should have probably reworded what I said, saying "you should allocate enough memory to store a bcrypt hash" rather than make it sound like you're storing the algorithm. I'll change that to help clear up any confusion. – CryptoAllDay Jan 20 '16 at 11:26
• PKBDF functions are supposed to be slow: that's one of their design goals. But you've missed my point: you're assuming the author wants PKBDF when he's just asking for a hash function (PKBDF are a special case of hash functions with additional properties). Without understanding what he'll use the function for, you can't suggest a solution. – Stephane Jan 20 '16 at 13:55

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.