SHA-1 Broken! CryptoSuite offer alternative hash?

Discussion in 'Other Ghost Security Software' started by LockBox, Feb 17, 2005.

Thread Status:
Not open for further replies.
  1. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,275
    Location:
    Here, There and Everywhere
  2. Jason_R0

    Jason_R0 Developer

    Joined:
    Feb 16, 2005
    Posts:
    1,038
    Location:
    Australia
    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.
     
  3. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,275
    Location:
    Here, There and Everywhere
  4. Jason_R0

    Jason_R0 Developer

    Joined:
    Feb 16, 2005
    Posts:
    1,038
    Location:
    Australia
    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. :)
     
  5. 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.
     
  6. spy1

    spy1 Registered Member

    Joined:
    Dec 29, 2002
    Posts:
    3,139
    Location:
    Clover, SC
    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
     
  7. Pilli

    Pilli Registered Member

    Joined:
    Feb 13, 2002
    Posts:
    6,217
    Location:
    Hampshire UK
    Hi Pete, ProcessGuard uses MD5

    Pilli
     
  8. Infinity

    Infinity Registered Member

    Joined:
    May 31, 2004
    Posts:
    2,651
  9. Pilli

    Pilli Registered Member

    Joined:
    Feb 13, 2002
    Posts:
    6,217
    Location:
    Hampshire UK
    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
     
  10. Infinity

    Infinity Registered Member

    Joined:
    May 31, 2004
    Posts:
    2,651
    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 :D



    yieehaaa, we are covered for some long time I guess *puppy*


    Inf.
     
  11. Jason_R0

    Jason_R0 Developer

    Joined:
    Feb 16, 2005
    Posts:
    1,038
    Location:
    Australia
    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. :)
     
  12. gottadoit

    gottadoit Security Expert

    Joined:
    Jul 12, 2004
    Posts:
    601
    Location:
    Australia
    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 :)
     
  13. Caratacus

    Caratacus Registered Member

    Joined:
    Jun 27, 2003
    Posts:
    164
    Location:
    Australia
    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."
     
  14. gkweb

    gkweb Expert Firewall Tester

    Joined:
    Aug 29, 2003
    Posts:
    1,932
    Location:
    FRANCE, Rouen (76)
    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.
     
  15. gkweb

    gkweb Expert Firewall Tester

    Joined:
    Aug 29, 2003
    Posts:
    1,932
    Location:
    FRANCE, Rouen (76)
    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.
     
  16. FanJ

    FanJ Guest

  17. NOD32 user

    NOD32 user Registered Member

    Joined:
    Jan 23, 2005
    Posts:
    1,766
    Location:
    Australia
  18. LowWaterMark

    LowWaterMark Administrator

    Joined:
    Aug 10, 2002
    Posts:
    17,873
    Location:
    New England
    Briefly since we don't take this thread off-topic... That's not a link you see in NOD32 user's signature, it's just a blue colored, underlined word. (Basically, it's a fake link so it's not clickable.) As for the ActiveX plug-in warning, that's because they used the SHADOW attribute from the bbcode list, which as you'll remember from this other thread causes an ActiveX plug-in alert if you have that item in IE set to prompt.
     
Thread Status:
Not open for further replies.