Announcement

Collapse
No announcement yet.

Google Announces First Practical SHA1 Collision

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • karolherbst
    replied
    Originally posted by Delgarde View Post

    If you're sending financial documents over the internet, you shouldn't be relying on mere checksums... you ought to be using full-on crypto - both encrypted and signed. Simply using a hash is no proof that the files weren't modified...
    they weren't critical, yet. But yes, if it is super important stuff, I would send them encrypted only.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by karolherbst View Post
    The point of hashes are to identify or check the integrity of files of course. Sometimes I have to send financially relevant documents over the internets and I have scanned files for this. Of course it has to be proven somehow that those files weren't modified in between.

    And because e-governance is becoming a thing, this is getting more and more important by the day.
    If you're sending financial documents over the internet, you shouldn't be relying on mere checksums... you ought to be using full-on crypto - both encrypted and signed. Simply using a hash is no proof that the files weren't modified...

    Leave a comment:


  • float
    replied
    Does anybody know if there is any plan for git to switch to a better hash?

    Originally posted by AndyChow View Post
    Still not really an issue. We typically use more than one type of checksum. Even if MD5 and SHA1 are falsifiable individually, they still aren't collideable together. So pass the SHA1, fails the MD5, doesn't help. Most times there are 3 different checksums done.

    And in that context, MD5 is still very useful. If it fails MD5, discard and move on. If it passes, then SHA1, SHA256, SHA512, then you know your file hasn't been tampered. Assuming the signature hasn't been compromised, which is more likely than trying to compromise the file by buffering it with some pixie magic that makes it collide.
    Do we? I am not aware of any protocol that allows signing more than one hash at once. Maybe openpgp allows it but even if it does, nobody uses that ability.
    In fact, an attacker could simply strip the signatures with the secure hashes and keep only the md5 hash, the message would probably be accepted as valid then.
    Last edited by float; 24 February 2017, 12:26 AM.

    Leave a comment:


  • willmore
    replied
    Originally posted by bug77 View Post

    The point is theoretical vulnerabilities have been known for a while. That article is 6 years old and only what I googled quickly while at work.
    That article wasn't about theoretical vulnerabilities. It was about the seemingly inevetable decrease in the cost of computing. This is a normaly type of analysis of crypto designs. If it takes X amount of processing to reasonably defeat a system, how long until a government can afford that? How long until organized crime? How long until a university? How long until someone who's bored and wants to play with AWS? That analysis of SHA1 hasn't changed and is still valid. How recent that analysis was done doesn't matter as the rate of computing cost per time is pretty constant. What that type of analysis leaves out is the possiblity that *some other kind of attack* can defeat the system more readily than was known at the time of the analysis. That is what has happened here. This is a new *class* of attack on SHA1. An unexpected one. Of course, they're always unexpected until they happen.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by AndyChow View Post

    You have either not read, or not understood, that paper.
    So exactly what does the linked paper say about cascading hashes? That it's exactly how I explained:
    A natural construction to build large hash values is to concatenate several smaller hashes. For example, given two hash functions F and G, it seams reasonable given a message M to form the large hash value (F(M)||G(M)). In this construction, F and G can either be two completely different hash functions or two slightly different instances of the same hash function. If F and G are good iterated hash functions with no attack better than the generic birthday paradox attack, we claim that the hash function F||G obtained by concatenating F and G is not really more secure than F or G by itself. Moreover this result applies both to collision restistance, preimage resistance and second preimage resistance.
    And to make matters worse here neither MD5 nor SHA1 even fulfil the requirements by this text since there exists better attacks against both than the generic birthday paradox, not to mention that even a generic birthday attack is MD5 is trivial.

    So having both a MD5 and a SHA1 hash does not make it any stronger than having only the SHA1 hash. Exactly why this is would take up far to much space here and I must therefore refer you to the linked paper.

    Leave a comment:


  • bug77
    replied
    Originally posted by willmore View Post

    I take it you didn't read the article?



    Google was pushing to have SHA1 removed by Jan 1 2017. Most people in the web industry weren't interesed in doing it until a few years later. Because of Googles insistance, Microsoft finally (last April) moved up their schedule to July/August of 2017. So, my assertion that Google is dragging the industry away from SHA-1 stands.
    The point is theoretical vulnerabilities have been known for a while. That article is 6 years old and only what I googled quickly while at work.

    Leave a comment:


  • willmore
    replied
    I take it you didn't read the article?

    n fact, in 2012 noted security researcher Bruce Schneier reported the calculations of Intel researcher Jesse Walker, who found that the estimated cost of performing a SHA-1 collision attack will be within the range of organized crime by 2018 and for a university project by 2021. Walker’s estimate suggested then that a SHA-1 collision would cost $2 million in 2012, $700,000 in 2015, $173,000 in 2018 and $43,000 in 2021.
    Google was pushing to have SHA1 removed by Jan 1 2017. Most people in the web industry weren't interesed in doing it until a few years later. Because of Googles insistance, Microsoft finally (last April) moved up their schedule to July/August of 2017. So, my assertion that Google is dragging the industry away from SHA-1 stands.

    Leave a comment:


  • DrYak
    replied
    Originally posted by OneTimeShot View Post
    For checksums to check you haven't accidentally got a corrupt file you could use CRC for all it matters...
    (though perhaps not exactly crc).

    I totally agree that in theory SHA-1 or MD5 or even CRC would be enough if you just want to check against corruption, or just need to hash something (as opposed to resist against an attacker). Rsync is still using MD4 and MD5 for that exact purpose.

    I would still stick with SHA-1 specifically, though, as it found on hardware implementations which make it easy.

    Also CRC doesn't have that good properties. If you want a light CPU hash, I would go for XXHASH64 (by LZ4's author). Better properties than CRC and much faster.

    Originally posted by karolherbst View Post
    It is today maybe, but not in the future. And then somebody suddenly finds a much better attacks and then it just takes 10 GPUs out of the sudden.
    As discussed above, it all depends on the use case.
    - If you use SHA-1 to detect intentional tampering by an adversary, Yup, it's time to shift to SHA-2 or SHA-3 already (and you shouldn't actually have waited to this but already started the push when SHA-2 became a standard).
    - If you simply use SHA-1 to detect file corruption (e.g.: because your target CPU has it as a handy hardware instruction), then SHA-1 is indeed good enough. Cosmic radiations and HDD bitrot won't specifically run Google's attack on GPU clusters with the malicious intent to produce collisions.

    Originally posted by AndyChow View Post
    Still not really an issue. We typically use more than one type of checksum. Even if MD5 and SHA1 are falsifiable individually, they still aren't collideable together. So pass the SHA1, fails the MD5, doesn't help. Most times there are 3 different checksums done.
    In theory, several hashes might be better than one single hash, but...
    - that's quite some useless complexity (And complexity is bound to attract implementation problems).
    - MD5 is way more primitive and simplistic, and negligible in run-time compared to SHA-1, therefore :....
    - ...MD5 will probably soon reach the point where collision are nearly trivial to make. Thus, it should be possible to add as simply an additional criteria in the SHA-1 search space (not simply brute force, but brute force combination that also happen to pass MD5), at maybe the cost of a small factor of additional GPU run time.
    (Compare this to the generation of "Vanity" bitcoin addresses : almost normal key pair generation, except the hash needs to start with a few selected letters. If this additional criteria is small and light enough (like a short nickname instead of trying to cram a whole play by shakespear in the hash) it's not much a penalty).

    Originally posted by F.Ultra View Post
    Does not work that way, according to this paper https://www.iacr.org/cryptodb/archiv.../1472/1472.pdf if you use multiple hashes for the same file the security is determined by the strongest hash and there is no added strength by the additional hashes.
    Exactly. As I said above, if you have 2 hases, H1 and H2, and the complexity of H1 >>> H2, you can simply ignore H2. The strenght of the H1|H2 stack is going to be basically the strength of H1.
    (Same situation as optimising steps - go for the slowest first - etc.)

    Originally posted by AndyChow View Post
    And in that context, MD5 is still very useful. If it fails MD5, discard and move on. If it passes, then SHA1, SHA256, SHA512, then you know your file hasn't been tampered.
    Instead of using a complex stacked construct, if your aim is to insure tamper-proof, go straight for the best available industry standard. Or the best available above all.
    So concentrate on SHA-2 or SHA-3 depending on your audience.

    Using a whole stack (MD5, SHA-1, etc.) is at best a waste of time, and at worst a big opportunity to make some mistake or end up only counting on SHA-1 in practice.

    Originally posted by AndyChow View Post
    Assuming the signature hasn't been compromised, which is more likely than trying to compromise the file by buffering it with some pixie magic that makes it collide.
    Not necessarily. Currently HMAC-SHA1 isn't compromised (yet). Public key signing for sufficiently long key (RSA >2048bits, ED25519, etc.) isn't either (yet).
    To spoof a file at the signing level you still need to steal the private key, or spoof it (So additional work at social engineering, or Certificate Authority bribing).
    To spoof a file at the hash level, you need to produce a malicious file with the same hash, so you don't even need to tamper with the signed hashfile. (currently possible with MD5, and soon with SHA1 - all within your bedroom or at least your own GPU cluster, without need for any interraction with a 3rd party).

    So no, signature isn't necessarily more likely to be compromised.

    Originally posted by droidhacker View Post
    Here is the thing;
    YOU know your password, your bank does NOT.

    Your bank knows a HASH of your password, which they use to calculate whether or not YOU know your password, and in many cases, this is an SHA1 hash.
    If your bank stores password as plain hashes you need to close your account IMMEDIATELY, and run as fast as possible.
    And chose your next bank as not having a website coded by a 14 year old in his bedroom.

    News flash, although there are still tons of stupid websites using this kind of shitty practice, any normal bank follows correct cryptographic procedure.

    At minimum:
    - a password is always stored salted (so 2 users having the same password will still get 2 different hashes due to different salts) thus preventing the possibility of rainbow table that you mention.
    - a password is always hashed with a specific PASSWORD-hashing function (a.k.a. a key derivation function). Not any random hash (like SHA-1, MD5, etc.) Usual standard is PBKDF2, new comers are Scrypt and Argon. (These functions are designed on purpose to run slow and eat tons of RAM. It's still realistic for a webserver to run them every now or then to check for identity only at log-in time. It's completely hopeless to run them millions per second on a GPU or on specialized ASIC to do bruteforce).

    At best:
    - use 2 factor identifications (OTP, chip card and reader, smartphone app, etc.) because no matter what security you throw at your password storage, stupid users are always going to use "Password1!" for absolutely all of their sites (but, it had an uppercase, and a number, and a special caracter ! It was secure according to the password meter ?) (Look on youtube for lectures by security experts about "password patterns" why in practice this is a shitty technique).




    DISCLAIMER:
    I am a doctor. I work in medical research and although I'm not a cryptographer (cue in Dr McCoy citation), information security is a pet peeves of mine.
    Last edited by DrYak; 23 February 2017, 03:03 PM.

    Leave a comment:


  • AndyChow
    replied
    Originally posted by F.Ultra View Post

    Does not work that way, according to this paper https://www.iacr.org/cryptodb/archiv.../1472/1472.pdf if you use multiple hashes for the same file the security is determined by the strongest hash and there is no added strength by the additional hashes.
    You have either not read, or not understood, that paper.

    Leave a comment:


  • molletts
    replied
    Though it's still not too easy to come by such an attack: Google's SHA1 "shattered" attack takes 110 GPUs one year of work to produce a collision while a SHA1 bruteforce attack on the other hand would take 12 million GPUs and a year worth of work.
    Originally posted by jass0 View Post
    The second occurance should surely be SHA256?
    The comparison is between a brute-force attack on SHA1 and Google's optimised "Shattered" attack, which makes it much quicker to find a collision.

    Leave a comment:

Working...
X