Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can...

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?


| 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 /

--
Dave
Multi-AV Scanning Tool - http://www.pctipp.ch/downloads/dl/35905.asp



Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?

wrote:

Quoted text here. Click to load it

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.

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?


| wrote:

Quoted text here. Click to load it


| 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."

--
Dave
Multi-AV Scanning Tool - http://www.pctipp.ch/downloads/dl/35905.asp



Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?

RayLopez99 wrote:
Quoted text here. Click to load it

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.

--

deadbeef

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?

ASCII wrote:
Quoted text here. Click to load it
Maybe it's time to use two different checksum alorithms. The chances
that two would collide would be pretty slim.

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?

FromTheRafters wrote:
Quoted text here. Click to load it

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

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?


Quoted text here. Click to load it

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

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?

RayLopez99 wrote:


Quoted text here. Click to load it

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

Re: Why do people not provide hash MD5 checksum algorithm outputs for suspect files, so we can check the number with FastSum?

Quoted text here. Click to load it

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.

Site Timeline