question
- Thread starter amped1980
- Start date
tlarkin
VIP Member
What is your higher goal in doing so?
TFT
VIP Member
tlarkin
VIP Member
The good way to hash things is for copy protection (though I am personally against all DRM type things) or applications that need to hash hardware information that is specific to a machine (like MAC address) which can be useful in some applications.
However, there is also a lot of "naughty" things you can do with that as well. If you have ever had to install Adobe products in mass you would know how annoying it can be.
However, there is also a lot of "naughty" things you can do with that as well. If you have ever had to install Adobe products in mass you would know how annoying it can be.
ok well...in response to the replies to my question
ok well i am taking a computer class and they say that it cant be done, and im not one to believe that. There had to be a way. This whole Hash stuff is new to me and when i was researching it on line there was a massive amount of confusing information.
ok well i am taking a computer class and they say that it cant be done, and im not one to believe that. There had to be a way. This whole Hash stuff is new to me and when i was researching it on line there was a massive amount of confusing information.
tlarkin
VIP Member
Nope, I just know that it works. Said algorithm takes information, runs it through to generate randomized hashcode with identifiers so they be used for whatever reason.
The first time you run photoshop CS3, it scans your computer and creates a hash code with hardware specific information so you can't run the same licensed copy on multiple machines.
You should research how DRM is coded, that will answer a lot of your questions.
ceewi1
VIP Member
Hashing isn't quite the same thing as encryption. Encryption requires that the encrypted file can be decrypted back to its original form at a later time, but hashing doesn't.
This is overly simplified, but should give you an idea of the basics.
There are a lot of uses for hashing, cryptography is just one of them. For example, let's assume I want to store information about people in an array using their name as an index. If I cater for names up to 10 characters I have about 1.4 trillion possible combinations. Allocating an array of size 1.4 trillion is obviously not feasible, so one way around this is to use a mathematical function, called a hash function, to reduce this number. For example, I could allocate the letters a-z with the numbers 1-26 and sum the value of each letter in the persons' name.
A person with the name 'bob' would hash to 2 + 15 + 2 = 19, for example.
This would give me 260 possible values (the 'biggest' would be zzzzzzzzzz which would hash to 260).
There is an obvious problem with this idea - it's possible for two people's names to have the same hash (e.g. person 'apb' would hash to 1 + 16 + 2 = 19 as well). This is called a collision, and if we were implementing this as an algorithm, we would need some sort of collision resolution scheme to deal with this situation.
We can extend this idea to cryptography - I don't want to store my password as plain text or else anyone could simply read it and use it. Instead, I apply my hash function to it and store the hashed version. If I try to login, the hash of the password I enter is computed and compared to the hash of my stored password. If they match, I am allowed access.
If we are foolish in our choice of hashing algorithm (e.g. the simple example above), the password can easily be broken. If my password were 'bob', for example (which hashes to 19), any other password which hashes to 19 would also be authenticated (e.g. 'apb'). Practical hashing algorithms use much more complicated hash functions, with enough possible hash values to make random guessing impractical (the sort of process that would take many years on a supercomputer).
Of course, if people are able to find and exploit 'bugs' in the algorithm being used, it may be possible to more quickly produce another password with the same hash value, and thus break the security.
With regards to files, we can do the same thing. I can take an executable, apply and the appropriate hash function to compute its hash. If this matches what I am told the hash should be, I know that my file is legitimate.
MD5, however, has been broken. By exploiting weaknesses in the algorithm it's possible to produce two files with the same MD5 hash. I could, hypothetically, produce a program - goodprogram.exe and distribute it. I could then replace it with another program - badprogram.exe which has the same MD5 hash and thus can authenticate as the legitimate goodprogram.exe.
This does not allow me to produce a program with the same MD5 hash as an existing file, though, which as yet cannot be done easily.
This is overly simplified, but should give you an idea of the basics.
There are a lot of uses for hashing, cryptography is just one of them. For example, let's assume I want to store information about people in an array using their name as an index. If I cater for names up to 10 characters I have about 1.4 trillion possible combinations. Allocating an array of size 1.4 trillion is obviously not feasible, so one way around this is to use a mathematical function, called a hash function, to reduce this number. For example, I could allocate the letters a-z with the numbers 1-26 and sum the value of each letter in the persons' name.
A person with the name 'bob' would hash to 2 + 15 + 2 = 19, for example.
This would give me 260 possible values (the 'biggest' would be zzzzzzzzzz which would hash to 260).
There is an obvious problem with this idea - it's possible for two people's names to have the same hash (e.g. person 'apb' would hash to 1 + 16 + 2 = 19 as well). This is called a collision, and if we were implementing this as an algorithm, we would need some sort of collision resolution scheme to deal with this situation.
We can extend this idea to cryptography - I don't want to store my password as plain text or else anyone could simply read it and use it. Instead, I apply my hash function to it and store the hashed version. If I try to login, the hash of the password I enter is computed and compared to the hash of my stored password. If they match, I am allowed access.
If we are foolish in our choice of hashing algorithm (e.g. the simple example above), the password can easily be broken. If my password were 'bob', for example (which hashes to 19), any other password which hashes to 19 would also be authenticated (e.g. 'apb'). Practical hashing algorithms use much more complicated hash functions, with enough possible hash values to make random guessing impractical (the sort of process that would take many years on a supercomputer).
Of course, if people are able to find and exploit 'bugs' in the algorithm being used, it may be possible to more quickly produce another password with the same hash value, and thus break the security.
With regards to files, we can do the same thing. I can take an executable, apply and the appropriate hash function to compute its hash. If this matches what I am told the hash should be, I know that my file is legitimate.
MD5, however, has been broken. By exploiting weaknesses in the algorithm it's possible to produce two files with the same MD5 hash. I could, hypothetically, produce a program - goodprogram.exe and distribute it. I could then replace it with another program - badprogram.exe which has the same MD5 hash and thus can authenticate as the legitimate goodprogram.exe.
This does not allow me to produce a program with the same MD5 hash as an existing file, though, which as yet cannot be done easily.
