• Advertisement
Sign in to follow this  

Using SHA-1 for small codes

This topic is 4396 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Imagine I have a small 5-byte code which I want to Hash, so that mr X wouldn't be able to find out what the code actually was; even if X had the hash. Trying to hash 5-byte codes by using brute force and comparing the results is simply too hard, so I'm not worried about that. However, is the SHA-1 function still safe for these small codes? I know that it's quite a detailed question but maybe some one knows around here :D I've been pleasantly surprised before at Gamedev :) Bas

Share this post


Link to post
Share on other sites
Advertisement
You have 5 bytes. The resulting hash is going to be 20 bytes. There won't be any information loss (meaning every possible 5 byte value will have a unique 20 byte hash, for information loss to happen, the hash would need to be smaller than the original data), but getting the information back will require brute force.

Brute forcing the original 5 byte value will require 500 billion attempts on average to find the original value, which isn't very much.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by smart_idiot
You have 5 bytes. The resulting hash is going to be 20 bytes. There won't be any information loss (meaning every possible 5 byte value will have a unique 20 byte hash, for information loss to happen, the hash would need to be smaller than the original data), but getting the information back will require brute force.

Brute forcing the original 5 byte value will require 500 billion attempts on average to find the original value, which isn't very much.


which is why you would want to pad the value with noise.

Share this post


Link to post
Share on other sites
Thanks smart_idiot.

After your remark about the 500 billion attempts I have decided to increase the number of bytes in the code to 10.

Share this post


Link to post
Share on other sites
I think he's refering to a salt, as is done when hashing passwords. I guess it depends on what is being hashed and why we're hashing it. It probably wouldn't work, because the salt with probably be kept with the hash, and so we would know what the noise was.

Share this post


Link to post
Share on other sites
Are you talking about using a hash of registration information to form some kind of registration key? Knowing the source of the X bytes and the intended use for both those bytes and the hashed value would help us know whether it's good enough or not. If not, we would then be able to suggest alternatives that fit the situation.

Share this post


Link to post
Share on other sites
Quote:
Original post by smart_idiot
I think he's refering to a salt, as is done when hashing passwords. I guess it depends on what is being hashed and why we're hashing it. It probably wouldn't work, because the salt with probably be kept with the hash, and so we would know what the noise was.
I'm sorry, I don't get it. Wouldn't adding some random data after the 5 bytes do exactly what he wants? He wouldn't store the random data as well as the hash, surely?
He could add some other redundancy check data to the data to be hashed as well, if required.

It's still a bit crazy generating a hash that is bigger than the data it is over though.

Share this post


Link to post
Share on other sites
iMalc: If you append random data to the X bytes, you'll change the hash value. Unless you also store/transmit the random data, you'll have no way to verify that the hash is correct. If you do store/transmit the random data, the purpose of adding the random data has been eliminated.

One possibility would be to use some kind of signature algorithm instead of hashing - the X bytes of data is used as an encryption key to encrypt data with a specific property (such as a psuedorandom sequence that has a particular weak hash value). If the server knows the X bytes of data, it could decrypt the psuedorandom sequence and ensure that the X bytes of data has that particular property.
The above is basically an adaptation of the HashCash idea.

Another possibility that would be suitable for cases where only one end has the 'magic bytes' would be to use some kind of public/private key encryption. Using only 128 bits (16 bytes) would allow a relatively strong key, and the public key could be given to anybody. That person could verify that another person has the private key by encrypting random data, having the other person decrypt it and send back a hash. Since the data is (psuedorandom), only the person with the correct private key could calculate the proper hash of the decrypted data.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Extrarius
iMalc: If you append random data to the X bytes, you'll change the hash value. Unless you also store/transmit the random data, you'll have no way to verify that the hash is correct. If you do store/transmit the random data, the purpose of adding the random data has been eliminated.


No, the purpose of salting is to prevent dictionary attacks. Someone might, for example, have generated hashes for all words in the dictionary, and stored in a database for future usage. Even by adding the salt "HELLO THIS IS MY SALT SO SUCK IT HACKER" to every data before hashing (and of course when verifying) would completely break the dictionary attack - who would have a pre-generated hash dictionary salted with exactly that string?

Now, let's have a real world example of where using a salt, any salt, would have helped.

Step 1:

$ echo -n trustno1 | md5sum
5fcfd41e547a12215b173ff47fdd3739

Step 2:
http://www.google.com/search?client=opera&rls=en&q=5fcfd41e547a12215b173ff47fdd3739&sourceid=opera&ie=utf-8&oe=utf-8

Are we convinced yet?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement