[REQ] Sha-1 support

[Hacker]

Ok, Sha-1 is dead, thanks Hacker.

Anytime.
If you ever have a problem with another hashing function, I'm your man...

Roman

[Sir_SiLvA]

So, wich

hashing function

should now be implemented?

As seen that nothing is secure I dont think that we need
any other as crc or md5 hardcode, or?

[icfu]

My request said "at least" Sha-1.

As seen that nothing is secure I dont think that we need any other as crc or md5 hardcode, or?

Such a fatalistic approach is not reasonable that's why I prefer to live with the best security I can get at any given time.

Icfu

[Sir_SiLvA]

Yeah and i meant that seeing that even Sha-1 ist not secure anymore would it not be better to get sha-1 support through a plugin, so that when one day there's something better as sha-1 one only has to replace the plugin?

And thats not fatalistic its only mho based on the fact that
everything mankind developes can be broken by mankind...

[icfu]

If I would request a feature that isn't hardcoded in TC already and is expected to be useless in the near future you would be completely right.

But, TC author has already decided that TC should include easy checksum creating/checking so I think we should not try to convince him that this feature is useless because the security can be broken in the future.

I prefer being able to double click checksum files instead of using workarounds like packer plugins or file system plugins so the only way for me is an integrated solution or an external exe or batch. Checksums are basic file operation needs and are worth to be included internally without any hassle.

Icfu

[Helix751]

This security compromise is really only relevant fro cryptographic (encoding, digitally signing, encrypting) purposes.

For the purposes of checking a downloaded file or a group of files burnt on CD integrity, almost any CRC algorithm would be quite fine, be it SFV (CRC-32), MD5 or SHA-1.

The possibility that a given downloaded file, in which a pair of bits may be changed or that was left incomplete or corrupted in any other way, the possibility of a casual matching hash with that of the original file is negligible.

[icfu]

You are right of course for accidental change of bytes, that was already expressed in this thread, but that's not the security concerns I mean. I am talking about code modification from viruses to make them fit a given hash of a program that is considered clean.

It's important that file downloads can be trusted and given hashs of original files cannot be faked by script kiddies.

Icfu

[icfu]

For all people being sceptical about that insecure MD5 is of no "real" danger, it is, PoC here:
http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0047.html

One extraction example:

* The attack itself is pretty limited -- essentially, we can create
"doppelganger" blocks (my term) anywhere inside a file that may be
swapped out, one for another, without altering the final MD5 hash. This
lets us create any number of binary-inequal files with the same md5sum.

[...]

Very interesting possibilities open up once the full attack is made
available -- among other things, we can create self-decrypting
executables (fire.exe and ice.exe) that exhibit differential behavior
based on their internal colliding payloads. They'll still have the same
MD5 hash.

So, in the future you cannot be sure if the file you download with a given MD5 hash is really original, at least some bytes can be changed and so give, let's say, "unwanted" results.

Icfu

[JackFoo]

As was stated in the original paper, and in the one you've linked, this problem's application is relevant only in a security sensitive enviroment. I'm somewhat in touch with the field (cryptography) and I still use crc32 when I need to be sure the file is ok (if there is no foul play suspected) and it (crc32) should be fine for almost every job (saying the same for MD5).

Why use CRC32 you ask, simple, speed, it's faster then any implementation of MD5 and much faster then SHA variants. That said, if the job is security sensitive than use sha256 and upwards (with HMAC), you could use sha256h (posted here in the forums) or other programs (fsum is good though I don't think it supports HMAC). All in all there really is no need for it in TC, it would be a waste of coding time and file size.

Cheers.

[icfu]

I don't see why this is only relevant in "security sensitive environments", sorry. Furthermore I really hope that more and more people are realizing that every system is "security sensitive", no matter if you are trying to download something or exchanging data with your bank account.

You are saying yourself

(if there is no foul play suspected)

and this is exactly what I am talking of: the evil ones, those you cannot trust and will begin spreading fake files because they are able to compute files with the same hash but corrupt file headers and other crap like that.
If the possibility is there people will do it, that's for sure.

I know about the alternative tools but I am requesting an internal solution nevertheless because I think it's important. ghisler has already shown interest in the file format so please don't call it useless, thanks.

Icfu

[JackFoo]

I don't see why this is only relevant in "security sensitive environments", sorry.

Simply because the amount of work required to 'hack' MD5 is beyond anything a normal user could generate (by normal I mean anything with less resources than say a Microsoft sized corporation or a small government) this is of course in todays terms (a short time period of say 5 years included). Expending so much resources on something not security sensitive is dubious at best. But if it is worth it than it is security sensitive and the whole point is moot.

I know about [...] so please don't call it useless, thanks.

Anything I say is IMO, so it is useless in my opinion. I didn't intend to start a fight I only wanted to clarify some points of a very badly advertised field (cryptography) which either gets too litle attention or suffers from over-zealousness, in short use the right tool for the right job.

P.S. 'broken' in cryptographic terms usually means it might be broken (in real world) in 10-150 years or might not be broken unless a very sophisticated alien lands and finds the code interesting.

Cheers.

[icfu]

Everything is possible with distributed computing, you will see the consequences sooner than you think I am afraid but as you are the expert here due to your knowledge I will be glad to be proven wrong in the near future.

Anyway, I would still request the internal solution because I don't need any more external tools for basic stuff, I am already overloaded with external workarounds so I am glad of every tool I can get rid of.

Icfu

[Bytec]

Well, all of You should know that there IS NOT and NEVER will be ANY collision free hash function. It is simply not posible.

About breaking MD5 and so on...

You should separate two different things
Knowing the message and its hash and then find another message with same hash is one thing, but finding message knowing only hash is something completely different!

Therefore those scientists in that pdf metioned earlier only found collisions, but they did not break MD5 or so. Finding collisions is not the same as breaking hash function! Remember, collisions exist in ANY hash function, the difference is only in probability of collision.

[Helix751]

I agree. MD5 and even CRC32 may be more or less secure, but as for verifying the integrity of files (the intended implementation embedded in Total Commander), the possibility of any algorythm of returning false positives is almost negligible. (note that "negligible" may mean, depending on your needs, as small as 0 or maybe not so small at all, but indeed little compared to the universe of possible cases)

There is a notable distinction between a brute force attack against any given algorythm to find collisions for any given data stream (be it an password, a file for integrity verification or a digital signature), and the possibility of a casual collision because of an unwanted change in the input data for the algorythm (file verification).

I agree with the request of SHA-1 support not really for replacing MD5 and/or SFV, but as a complement for added compatibility and, as icfu states, avoid using another external tool.

[Saso]

SHA1 added as third checksum variant would be cool indeed. About standards ... In Linux/UNIX you use .sha1 extension and format is like for MD5, that is:

hash *filename
('*' should indicate binary files but its used for all anyway)

In example:

filename:
KNOPPIX_V3.7-2004-12-08-EN.iso.sha1

contents:
f0c1cde8b05546fff5205039a0d376bebab25308 *KNOPPIX_V3.7-2004-12-08-EN.iso

( i saw this @ http://ftp.knoppix.nl/os/Linux/distr/knoppix/ and other pages )

But please dont remove CRC32 and MD5!