SHA-1 Broken! CryptoSuite offer alternative hash?

http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
Maybe RIPEMD-160?
Who would have thought?

 

How does this affect CryptoSuite though? CryptoSuite uses SHA-256 in the generation of keys from passwords, along with another hash. SHA-256 has not been "broken". It still takes 2^69 of work to break SHA-160.

 

You are right. I was thinking of a different program entirely. However, the best I've read on this breaking story is from Justin Troutman. Read the last post on this page:
http://www.security-forums.com/foru...&start=0&sid=7e35add0bb526f5022a2848e6e20b293
Very interesting.....Justin is just plain good.

 

Justin's post in that thread is a good rehashing of what has been said by others. It seems everytime an event like this occurs there is a bunch of people who need to restate the obvious. If you check from the first source (Schneiers page) you'll find some other interesting comments there.

There wasn't a successful brute force of MD5 (2^64) and this new attack still needs 2^69 work to find a collision. Yes SHA-1 is broken if this attack isn't fraudulent, that's obvious isn't it? All this means is *IF* you rely on SHA-1, it's time to migrate away from it, there is no reason to panic or get worked up about it. When you migrate to something new, choose the most secure hash and wait for that to be broken.

 

Justin stated a lot more than just the obvious. Some people have to act like they "have everything under control" and know all the angles of everything. That's what your post was about.

 

Jason - I know you're on your own now, but could you tell me if ProcessGuard needs to be changed to different libraries now that this issue has come to light?

And if so, would you be a part of helping to fix it? Pete

 

Hi Pete, ProcessGuard uses MD5

Pilli

 

Hi Pilli,

like md5 doesn't have this kind of "issues"...

http://www.hcrypto.com/B/

http://www.computerworld.com/printthis/2004/0,4814,95343,00.html


I don't think this will affect pg at the moment though...


Inf.

 

Thanks for the links Infinity,
Yes, They are throwing a lot computer power at it that's for sure
If it get's anywhere near the stage where it can effect the efficacy of DCS programs, DCS have already stated that the necessary changes will be made.

Pilli

 

yes true and I believe that , no prb

what I was thinking: if something was going to change the md5 hash pg would block it anyway



yieehaaa, we are covered for some long time I guess


Inf.

 

Hi Pete, I have seen no two WIN32 executables which have been shown to have the same MD5 HASH from the recent attack, so no I don't think currently it will affect PG. In the future it may or it may not, if it does there will be a buffer between when the information is released and when malware starts to implement it. It should be fairly simple to change the hash in PG when this event occurs. But for now MD5 is fast and secure for what PG needs it for.

 

Without trying to "restate the obvious"

The computing power required to find a collision is a little expensive right now
With the continuing rise of botnets its not too hard to imagine that someone will put all that distributed computing power to work at some point (for something less useful than finding ET or solving medical problems)

As long as the different layers of security on your OS use different methods to hash the executables, then its going to be a lot harder to get something past them. I'm not sure what the different personal firewalls with app execution protection use for their execution protection and I'd prefer not to have to care

When PG v2 did a hash using just the first part of the executable file it was good in a way, because it did mean that the PG hash would be different to the App firewall hash and that difference would work in our favour

One way to make sure that PG will always be different no matter what algorithm is used, is to perform the hashing calculations in an arbitrary but consistent way (for a single customer) and still provide coverage for the entire file (or subset of the file if that is all that is being checked).

Here is one idea to pick holes in fwiw

PG could break the file into multiple pieces (2 would be enough) using some arbitrary metric (known only to those who compile or decompile PG . If the license string was used to randomise the size of each piece then everyone's PG would behave differently and still be consistent within one environment (ie: to allow the binary hash files to be copied around identical PC's during deployment with common license keys - that is until PG has an import/export feature added... hint hint)

Once a file is having checksums computed on differently sized chunks of file, it is highly likely that PG's hash will be different to other applications and therefore make it a lot harder to create an executable that would bypass *both* the App Firewall or other software checksum and the PG checksum.

So even if you allow a *nasty* program to run it wouldn't be feasible for someone to have precomputed a hash in advance to replace a system file or app executable simply because you have at least doubled the difficulty of the computations by requiring 2 hashes to be computed. One hash is required for the entire file to bypass the app firewall (which can't be killed because of PG) and the other so that the first "chunk" of the file could be replaced with a malware startup routine, then because the "chunk" size is variable and different for each PG user, someone would really have to care to target you as an individual

Not particularly compute intensive if the chunk size is computed at startup and held in memory... it would invalidate all the executable signatures when changing from PG free to PG paid which could potentially be annoying (unless the extra checking is controlled in an advanced options screen and if the option is chosen the user could wait for a few mins while the *all* the executable checksums are verified and recomputed...)

When you consider that its probably only a handful of cloak and dagger government organisations with a few spare supercomputers that would be able to do this right now. Give it time and someone will try and use a big botnet for something compute intensive instead of disrupting some companies Google click through advertising campaign

Anything like this still amounts to busy work when you consider how many other real threats there are out there today

Getting ready for the threats of tomorrow seems like such a waste of time, that is, until the 0day exploit comes along

 

Check out this page:

http://www.fcw.com/fcw/articles/2005/0207/web-hash-02-07-05.asp

"Federal agencies have been put on notice that National Institute of Standards and Technology officials plan to phase out a widely used cryptographic hash function known as SHA-1 in favor of larger and stronger hash functions such as SHA-256 and SHA-512."

 

The "128bits" and the "2048bits" in your same sentence is confusing, this is not the same thing at all. I don't know if you know it or not, may be yes and even better than me, but since I found you sentence possibly confusing I just want to explain things clearly.

We use every day 128bits symetric encryption, which is very secure (in itself).
Then sometimes softwares use 2048bits asymetric encryption which is a lot weaker than the symetric one. This is two completly different things.
A 256bits symetric encryption is far stronger than a 4096bits asymetric one.

Often asymetric is used for authenticating, and symetric for crypting the communication, as it is the case in CryptoSuite.

Regards,
gkweb.

 

Yes I was saying that 128bits symetric ciphers (AES, Twofish, etc...) is stronger than 2048bits asymetric cipher (RSA for instance).

In symetric you just has one key to encrypt/decrypt.
In asymetric you have a public key with which you can encrypt, and there is a private key to use to decrypt. Because there is a mathematical relation between the public key and the private key, this system is basically weaker, and requires very higher key length to ensure a least security.

Both symetric/asymetric ciphers can be used to encrypt data, however handling 4096bits key (or even a lot more to reach a 256bits symetric encryption strenght) uses a lot more ressources than to use a small 256bits one.
So because symetric is safer and faster it is used in communications, however asymetric ciphers are more convenient because anyone can send you encrypted data that you will be the only one able to decrypt (thanks to the private key).

Then so we have the perfect combo : asymetric is used to authenticate you (very short step), for instance I guess that you send your public key, the server send back to you the symetric key (encrypted with you asymetric public key) that you will have to use to communicate, and you are the only one able to decrypt it with your private key... at least that is how I imagine it works

About the relation between asymetric/authentication and symetric/communication, Jason will probably be more precise than me

Regards,
gkweb.

 

A little bit off topic:

For those interested, there is an archived thread with some quotes from Wayne, Jason and Joseph about some HASH algorithms:
https://www.wilderssecurity.com/showthread.php?t=7276

And for an introduction to basic encryption techniques you might like to read here:
http://webmonkey.wired.com/webmonkey/backend/security/tutorials/tutorial1.html

 

LMAO @ b4rtm4n(SFDC Mod)
"All posts are ROT-26 encoded for security."