PureBasic Forums - English

Check sums usually reside within a discrete field; e.g. a 32-bit checksum has a total of only 2^32 distinct checksums possible. If there are more than 2^32 possible 'inputs' then there will inevitably be more than one such 'input' yielding the same checksum. This makes a 'reverse' formula impossible.

srod wrote:Check sums usually reside within a discrete field; e.g. a 32-bit checksum has a total of only 2^32 distinct checksums possible. If there are more than 2^32 possible 'inputs' then there will inevitably be more than one such 'input' yielding the same checksum. This makes a 'reverse' formula impossible.

Other interesting questions are:
- Given a checksum, can you programatically generate an input with this checksum?
- Given a checksum and an arbitary input, can you programatically add bytes at the end of the input so that it matches the checksum?

Given a checksum, can you programatically generate an input with this checksum?

I would say that there would in general be no reliable way because of the inevitable 'many-one' link between possible inputs and checksums. Try reversing a MD5 hash for example! Beside's, checksums are normally applied to large chunks of data anyhow which makes it inherently difficult to reverse the checksum!

srod wrote:

Given a checksum, can you programatically generate an input with this checksum?

I would say that there would in general be no reliable way because of the inevitable 'many-one' link between possible inputs and checksums. Try reversing a MD5 hash for example! Beside's, checksums are normally applied to large chunks of data anyhow which makes it inherently difficult to reverse the checksum!

Since there is a many-to-one link we obviously cannot go from the one to "all". The question is if we can find just one of the "many" (preferably a short one). This is interesting because user databases often store the password as a hash. So that even if you can access the database, you can not get the password of a given user.
The login software compares the hash of the given password with what's stored in the database. So to login, you don't need the password, you just need a password string with the same hash as the password.

Of course, hashing algorithms are made to prevent this sort of "reverse hashing". But just because it's difficult doesn't mean it's impossible with all hash algorithms.

(This kind of security problem is why Linux has switched from DES to MD5 or even SHA for password hashing.)

The same with most password systems I have encountered (e.g. Windows users system file! )

MD5, for example, usually requires brute force to 'reverse' and even then some knowledge of how the 'input' is structured is required.

MD5, for example, usually requires brute force to 'reverse' and even then some knowledge of how the 'input' is structured is required.

Rather, a better method than brute force isn't known yet.

Oh wow, wouldn't it be fun to pass around programs as quickly as you can copy and paste a hash.

Copywhat?

As quick as passing a hash?
Reminds me of Blazemonger

@Trond, what you're thinking about is called collisions. And yes, due to the nature of hashes collisions are always possible.
so yeah data can be edited so that a two files can have the same hash, but it's damn difficult and incredibly time consuming.

@All
And do not forget that a hash can only reliably tell you if two files (or datasets) are different.
In other words, if the hashes do not match then you can trust that the data or files ARE different.

If the hashes match you got a dilemma, the probability that the files or data are identical is very high,
but there is still a chance that they are different, so using additional sources of info like filesize or datasize,
and filename, or header check, or datestamp check etc is always advised.

The only 100% certain way to check if two files are identical is to do a byte by byte comparison.

But hashes thankfully exist so they give you a quick way to check if two files are different.

I know, it's kinda confusing. "A hash is useful for checking if two files are different, but not if two files are identical." Even my head hurts a little.

Checksum errors unrelated to Ingres where the solution was to disable the offload of the checksum calculation in the network adapter.. A checksum is a way to check if a file or information has errors. When you hack the games, you don't change the info at the beginning of the ROM to make it think the colour palletes you changed (or other things in the hack) are the correct ones; thus giving you a "checksum error".

Rescator wrote:"A hash is useful for checking if two files are different, but not if two files are identical."

plainly clear and absolutely comprehensible.
sentences that tell the truth are often like that.
you don't need Zen or Chaos Math to understand such.