Why do people not provide hash MD5 checksum algorithm outputs forsuspect files, so we can check the

[RayLopez99]

Subject line says it all. I notice on public site that try and
identify a suspect file, often users will relate their experiences but
even experienced users will never mention the checksum. If they did,
we could use a checksum hash finder like FastSum to verify if the file
has been tampered with.

Why don't people refer to checksums more often? Is it because (as I
suspect) that there is no one 'standard' way of calculating checksums,
so different programs will give different numbers? Even if so, you
would think at least the most popular algorithm (FastSum?) would be
mentioned.

RL

 

[David H. Lipman]

From: "RayLopez99" <[email protected]>

| Subject line says it all. I notice on public site that try and
| identify a suspect file, often users will relate their experiences but
| even experienced users will never mention the checksum. If they did,
| we could use a checksum hash finder like FastSum to verify if the file
| has been tampered with.

| Why don't people refer to checksums more often? Is it because (as I
| suspect) that there is no one 'standard' way of calculating checksums,
| so different programs will give different numbers? Even if so, you
| would think at least the most popular algorithm (FastSum?) would be
| mentioned.

http://www.win.tue.nl/hashclash/SoftIntCodeSign/

 

[ASCII]

Subject line says it all. I notice on public site that try and
identify a suspect file, often users will relate their experiences but
even experienced users will never mention the checksum. If they did,
we could use a checksum hash finder like FastSum to verify if the file
has been tampered with.

Why don't people refer to checksums more often? Is it because (as I
suspect) that there is no one 'standard' way of calculating checksums,
so different programs will give different numbers? Even if so, you
would think at least the most popular algorithm (FastSum?) would be
mentioned.

RL

The standard for the longest time was the 32 bit cyclic redundancy check,
but as the 128 bit algorithm five message digest provides a more unique result
so that it has now become the second (if not the) most popular.

 

[FromTheRafters]

The standard for the longest time was the 32 bit cyclic redundancy check,
but as the 128 bit algorithm five message digest provides a more unique result
so that it has now become the second (if not the) most popular.

Maybe it's time to use two different checksum alorithms. The chances
that two would collide would be pretty slim.

 

[ASCII]

Maybe it's time to use two different checksum alorithms. The chances
that two would collide would be pretty slim.

The secure hash algorithm and the variety of bit strengths available such as
the SHA256 give pretty strong values on their own.
Or use a multi algorithm application like: HashCalc http://bit.ly/hCcje6

 

[RayLopez99]

The secure hash algorithm and the variety of bit strengths available suchas
the SHA256 give pretty strong values on their own.
Or use a multi algorithm application like: HashCalchttp://bit.ly/hCcje6

Yes but my point is that people who publish files never say what the
hash actually is! You have to ask other users "What is your hash?"
and then rely on strangers to give you an honest answer.

RL

 

[RayLopez99]

http://www.win.tue.nl/hashclash/SoftIntCodeSign/

--

Thanks for this, it was interesting.

However, if you read it carefully you see they are really talking
about something slightly different: s/w integrity or code signing.
That's when you download a file and want to make sure you did not make
a mistake, or download malware.

My question is different: suppose you find a file on your PC that you
think is malware. You should be able to go to the source of the file,
say Microsoft, and ask them what the SHA1 hash (or some other hash)
is. Then you can check out the hash and see if they match. This
paper specifically addresses the issue of how you can confuse the hash
to look like malware or a legitimate program, but it assumes the user
does not know what the 'good' hash signature is for the legitimate
program (read the abstract carefully and see). I'm saying publishers
should publish what the good hash is.

RL


It is important to note that the hash value shared by the two
different files is a result of the collision construction process. We
cannot target a given hash value, and produce a (meaningful) input bit
string hashing to that given value. In cryptographic terms: our attack
is an attack on collision resistance, not on preimage or second
preimage resistance. This implies that both colliding files have to be
specially prepared by the attacker, before they are published on a
download site or presented for signing by a code signing scheme.
Existing files with a known hash that have not been prepared in this
way are not vulnerable.


MD5 should no longer be used as a hash function for software integrity
or code signing purposes.
By now, everyone should be aware of this. If you are still using MD5,
it would be good to carefully analyse the risks that result from its
continued usage.
Note that also the collision resistance of SHA-1 does not live up to
its design criteria anymore, though attacking SHA-1 is still much more
difficult than attacking MD5. See the IAIK Krypto collision website
for the present state of affairs.

 

[ASCII]

RayLopez99 wrote:

Yes but my point is that people who publish files never say what the
hash actually is! You have to ask other users "What is your hash?"
and then rely on strangers to give you an honest answer.

Why ask others, won't the original poster supply a hash?

 

[David H. Lipman]

From: "RayLopez99" <[email protected]>


| Thanks for this, it was interesting.

| However, if you read it carefully you see they are really talking
| about something slightly different: s/w integrity or code signing.
| That's when you download a file and want to make sure you did not make
| a mistake, or download malware.

| My question is different: suppose you find a file on your PC that you
| think is malware. You should be able to go to the source of the file,
| say Microsoft, and ask them what the SHA1 hash (or some other hash)
| is. Then you can check out the hash and see if they match. This
| paper specifically addresses the issue of how you can confuse the hash
| to look like malware or a legitimate program, but it assumes the user
| does not know what the 'good' hash signature is for the legitimate
| program (read the abstract carefully and see). I'm saying publishers
| should publish what the good hash is.

| RL


| It is important to note that the hash value shared by the two
| different files is a result of the collision construction process. We
| cannot target a given hash value, and produce a (meaningful) input bit
| string hashing to that given value. In cryptographic terms: our attack
| is an attack on collision resistance, not on preimage or second
| preimage resistance. This implies that both colliding files have to be
| specially prepared by the attacker, before they are published on a
| download site or presented for signing by a code signing scheme.
| Existing files with a known hash that have not been prepared in this
| way are not vulnerable.


| MD5 should no longer be used as a hash function for software integrity
| or code signing purposes.
| By now, everyone should be aware of this. If you are still using MD5,
| it would be good to carefully analyse the risks that result from its
| continued usage.
| Note that also the collision resistance of SHA-1 does not live up to
| its design criteria anymore, though attacking SHA-1 is still much more
| difficult than attacking MD5. See the IAIK Krypto collision website
| for the present state of affairs.


MD5 is used and the important part on the web page starts...

"We now present our proof of concept pair of Win32 executable files that have different
functionality but identical MD5 hash values."

 

[idbeholda]

Yes but my point is that people who publish files never say what the
hash actually is!  You have to ask other users "What is your hash?"
and then rely on strangers to give you an honest answer.

RL

This is why I have my scanner generate a complete list of md5 hashes
for files that is compatible with google's md5 blacklist hash list and
the NSRL's whitelist library. Admittedly, I think you're a bit naive.