Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Encryption Security IT

More on Newly Broken SHA-1 362

AnonymousStudent writes "Details are out about the reported broken SHA-1 hash function. The findings are that SHA-1 is not collision free and can be broken in 2^69 attempts instead of 2^80. This is about 2000 times faster. With todays computing power and Moores Law, a SHA-1 hash does not last too long. Using a modified DES Cracker, for the small sum of up to $38M, SHA-1 can be broken in 56 hours, with current computing power. In 18 months, the cost should go down by half. Jon Callas, PGP's CTO, put it best: 'It's time to walk, but not run, to the fire exits. You don't see smoke, but the fire alarms have gone off.' As Schneier suggests, 'It's time for us all to migrate away from SHA-1.' Alternatives include SHA-256 and SHA-512."
This discussion has been archived. No new comments can be posted.

More on Newly Broken SHA-1

Comments Filter:
  • by Sam Ruby ( 8995 ) on Saturday February 19, 2005 @10:38AM (#11721967) Homepage
    The new SHA-1 break only affects very carefully constructed messages. This means that it is completely useless for an attacker impersonating an existing message, unless that message was purposely constructed to be attackable. The attack is only useful if the attacker creates both messages, and the attacker can choose the exact format of both messages.
    • by johnhennessy ( 94737 ) on Saturday February 19, 2005 @10:48AM (#11722035)
      Totally agree, however in the crypto community (which I cannot claim to be part of) the consensus is generally that if a weakness if found in an algorithm then it begs the question - "what other weaknesses are there".

      Once an algorithms strength is in doubt by the presence of even one weakness people feel very reluctant to trust it.

      Its probably up to everyone to see how this affects their own circumstances. Crypto is always about Knowing your enemy (the paranoia has now kicked in !). When picking a scheme one always makes a number of assumptions - Who are you keeping the information hidden from, what resources do they have, how badly do they want it.

      No crypto is powerful, or clever enough (yet!) to be completely unbreakable so its all down to making assumptions:

      1)
      Would someone be willing to pay $38 million (assuming this is correct) to get my credit card number - probably not.

      2)
      Would someone be willing to pay $38 million to get insider info on a merger between two banks - each worth over $10 billion.

      What unsettles people is that their previous assumptions on SHA-1 are now invalid.

      • Price (Score:3, Interesting)

        by Uber Banker ( 655221 )
        The £38mn is to build the machine. It is in 1-time use for 56 hours.

        There are 8776 hours in a year. Assume the machine has a life of 3 years before it becomes obselete. That means (discouting TVM at 0% for simplicity) the machine can do 470 problems of this type in three years, breaking even at a little over $80 per problem.

        Damn that just got a lot lot cheaper.
        • Re:Price (Score:5, Informative)

          by Uber Banker ( 655221 ) on Saturday February 19, 2005 @11:34AM (#11722277)
          Apologies, $80k per problem.
        • Actually, as long as people continue to use SHA-1 for more than 3 years and they can keep the machine running, they can continue to work a lot more problems. ;)
          • Indeed, but we should also discount future revenue streams, etc. In 3 years the computation power of the machine will become obseleted meaning it would take a lot longer to work on a problem than a competitor machine, and would have to reduce the price of its service significantly. Usually high-power computers are written down in company accounts to zero value over 2-5 years.

            Perhaps we should risk-weight the investment too... this is all getting technical and I fear we may incriminate ourselves on plan
            • Re:Price (Score:3, Interesting)

              by tonsofpcs ( 687961 )
              Yes, but if you solved the first 3 years worth of problems seeing it costing 80k per problem, then the next problem would only cost you the power needed to run the machine, your 38M is already paid off.
      • 1) Would someone be willing to pay $38 million (assuming this is correct) to get my credit card number - probably not.
        He needs to pay the 38 million only once and can get a million every second day - sounds like a good deal. But OTOH his interest might be different, as you said in your bank merger example. However, there are things that are worth a lot although it is not as obvious as in this case. (Research stuff leading to military and industrial advantages.)
      • by Vellmont ( 569020 ) on Saturday February 19, 2005 @12:07PM (#11722522) Homepage

        2)
        Would someone be willing to pay $38 million to get insider info on a merger between two banks - each worth over $10 billion.


        Except SHA-1 isn't an encryption scheme, it's a hashing algorithm. For your 38 million you could construct an machine that would create two random messages that hash to the same value. Totally useless. Really what you want to do is find a message that hashes to the same value of a specific message. Or even better you'd want to create an arbitrary message, tack on some header or footer and have that hash to some chosen hash.

        If I understand message signing and digital signatures, an attacker wants to make it look like they're the intended target. Say I send a signed message to my bank saying "please transfer $1,000,000 to account 123456". An attacker wants to generate a message like "please transfer $1,000,000 to account -attacker account number- that will hash to the same value, so he/she can use the same signed digital signature. The 38 million dollar device won't be able to do that in 56 hours, I doubt you could do it in 56 years (and I highly suspect it would take MUCH MUCH longer).
        • For your 38 million you could construct an machine that would create two random messages that hash to the same value. Totally useless.

          Not true. The use of that is creating one legitimate document and apply a certification to it, with the authority of a trusted certifier (who would have verified it, because it is legitimate).
          At the same time your $38M machine would create a second document, with whatever information you care to put in, which that certifier would never touch. They have the same hash, so y

          • Not true. The use of that is creating one legitimate document and apply a certification to it, with the authority of a trusted certifier (who would have verified it, because it is legitimate).


            The is that as soon as you try to place specific content in the message, it becomes *much* harder to find a collision that meets your requirements (especially if there are length requirements too).

            Now.... Let me bring up one possible use of these issues. If you store passwords as SHA hashes, and if someone can ge
      • For 2, it's still cheaper to buy an insider.
    • by arkhan_jg ( 618674 ) on Saturday February 19, 2005 @10:57AM (#11722079)
      Yes, but say someone creates a document (such as a contract) for you to digitally sign.

      If they're prepared to spend a realistic level of time on it they could create two of them that hash to the same thing, with a small but effective change to the second.

      You sign the first with SHA-1, but your signature also matches on the second, putting you in a weak position when you try and claim "I didn't sign _that_!"

      The time/money requirements to do this aren't really practical yet, but they will be soon.

      As the sub says, time to start shifting off SHA-1.
      • And you only have to construct 2^69 different contracts with the same meaning.

        Creating pseudo-random numbers that hash to the same value != making any arbitrary document hash to the same value.

      • I presume that finding two colliding contracts both written in a meaningful and legally binding language is harder than finding a simple collision.
        • by Sweetshark ( 696449 ) on Saturday February 19, 2005 @11:37AM (#11722308)
          I presume that finding two colliding contracts both written in a meaningful and legally binding language is harder than finding a simple collision.
          Write the contract in MS Word and use huge uncompressed BMPs for the company logos. You have instantly enough space for subtile changes to create collisions.
      • Or, and this is a good one, you could do that. For any message that I create, and sign for SHA-1, it's now possible that I created another duplicate message, and that I could, at any point in the future, say "Oh no, I didn't sign _that_!"

        So, there are two lessons to be learned.
        1. Don't trust SHA1 as part of an algorithm for signing a document that someone else gave you. Actually, this is not so much of a risk, because any reasonable signature algorithm signs more than just a straight hash of the document.

      • [NB: For computer science geeks, a "pre-image of a hash" is more or less the same thing as a "bucket"; for math geeks, it's more or less the same thing as a "variety".]

        If they're prepared to spend a realistic level of time on it they could create two of them that hash to the same thing, with a small but effective change to the second.

        I dunno - my guess would be that the subspace of all grammatically correct English language sentences [and paragraphs, and chapters/essays/"contracts"] is, for all intent

  • by baadger ( 764884 ) on Saturday February 19, 2005 @10:38AM (#11721974)
    "The findings are that SHA-1 is not collision free"

    Since when is it possible to have a collision free hash when the hashed data has more possibile bit combinations than the hash itself?

    Genuine question.
    • by HeghmoH ( 13204 ) on Saturday February 19, 2005 @10:45AM (#11722016) Homepage Journal
      This is cryptography, so it's always talking about possibilities.

      With 160 bits of hash, the probability that two pieces of data will hash to the same value is incredibly low. Using a brute-force technique, you'd have to use all of the computers on the planet for thousands of years to find a collision. This is, for all intents and purposes, "impossible", and thus the hash is effectively collision-free.

      With the new findings, a wealthy organization could actually find a collision with a reasonable amount of money and time.
      • by mre5565 ( 305546 ) on Saturday February 19, 2005 @12:10PM (#11722536)
        With 160 bits of hash, the probability that two pieces of data will hash to the same value is incredibly low.

        The width of hash has little to do with the probability of a collision by an attacker. The cleverness of the hash algorithm is the key to collision resistance. For example, a checksum is a hash that merely breaks the int into 160 bit chunks, adds each chunk to together, takes the lower 160 bits of the sum, resulting a 160 bit hash. It is trivial to find for any given message, multiple messages that checksum hash to the same value. Thus far, no one has proven they can do that with SHA-1 (or MD5 for that matter), at least not trivially.

        Of course, once one has a clever algorithm, width of the hash can be a nice factor in building up its strength, assuming the hash algorithm lends itself to scaling that way, as SHA apparently does, with SHA-256, SHA-512 being available.

        Of course, for random data corruption due to faulty hardware or software, a 160 bit checksum would be excellent (if costly) protection. But that isn't what we are talking about here.

    • by IWannaBeAnAC ( 653701 ) on Saturday February 19, 2005 @10:45AM (#11722017)
      It simply means that it is possible to find a collision without a brute-force scan of O(2^80) messages. Instead, because of weaknesses in the algorithm, it is only necessary to scan O(2^69) times.
    • It's not. I'm sure there is some law, but if you are hasing data that has more data than the hash itself, there are going to be collisions.

      (Stupid Mean Girls quote)"Anything else is like...against the laws of feminism or something!"

    • Obviously, it's not. The article is also not "new" information by any account (everything said was in B.S.'s original blog entry).

      I also want to stress that while this is a blow to the faith we placed in SHA-1 (why were we trusting a hash invented by the NSA, anyway?) it doesn't do much for most uses of SHA-1. For example, it could allow you to perform a successful man-in-the-middle attack against an SSL-encrypted HTTP session, but the user might notice something was up when response times were measured in
    • It's important, when we speak of using cryptographic algorithms, to distinguish between "impossible" and "infeasible". Given enough processing power and enough time, any key can be cracked. The question is one of feasibility: By the time you crack the key and use it to extract the information, (a) would the information still be relevant and useful to you? and (b) would your fourth-generation decendent be the person who actually cracks the key in your place?

      It's quixotic to look for an algorithm that is
    • An idea: This could be a good thing. If there was a one-one relationship, then that would mean theoretically there could be an inverse function to "expand" the hash. Given that there are going to be collisions, this may give us (if only a little) more confidence that hashes are not reversible.
    • I spoke about this at length, how absurd stating that they have found that any data being hashed into a smaller data space 'has colisions', and got modded a troll.

      I think the first ever boring lecture I had was on memory paging and has colision detection of paging algorithms... that is right, hash colisions.

      Now, there seems to be too much huff and puff and not enough actual insightful talk about what this actually means, which means the fallout of this will bea bout 68.5 /. articles all being submitted by
  • SHA-1 (Score:5, Funny)

    by mboverload ( 657893 ) on Saturday February 19, 2005 @10:38AM (#11721976) Journal
    SHA-1? pshhhh. They should be using SHA+1. Thats 2 more!
  • Hmmm (Score:5, Informative)

    by Lisandro ( 799651 ) on Saturday February 19, 2005 @10:40AM (#11721987)
    The findings are that SHA-1 is not collision free and can be broken in 2^69 attempts instead of 2^80.

    Well, doh - it's a hash you silly, there will always be collisions.

    Anyway, it's nothing to panic about really. The ammount of computer power needed to crack it is still massive. Unless you're investigated by the NSA, SHA-1 will be fine for quite a while.
    • Follow-on work (Score:5, Informative)

      by fhmiv ( 740648 ) on Saturday February 19, 2005 @11:02AM (#11722106) Homepage
      The concern is not so much that the method described in this break is feasible on today's hardware, or even that this method will get cheaper and cheaper as hardware gets faster. The BIG concern is that this method provides insight in to the SHA-1 in general, and will be used by others to come up with more efficient breaks or more egregious flaws.
      • Yes, but again: in time. Unless someone comes up with a way to hash SHA-1 one millon times faster than now, it's still a damn good hash algorithm (hard to crack, fast, and easy to implement). Never mind it's uses beyond criptography.

        I can see the importance of this announcement -it IS a major one, but if someone thinks he has to dump SHA-1 inmediatly because script kiddies might mess with his computer, he's far away from the truth. 2000 times faster than "takes a long fucking time" still takes a long fu
  • This is big... (Score:4, Interesting)

    by A beautiful mind ( 821714 ) on Saturday February 19, 2005 @10:41AM (#11721993)
    We need to develop algorithms aside of SHA. SHA-256 only postpones the problem...
    • So I guess SHA-256 is slower than SHA-1, right?

      Why not just use SHA-2048, that wont be broken for like...6 years.

    • Re:This is big... (Score:5, Informative)

      by m50d ( 797211 ) on Saturday February 19, 2005 @10:48AM (#11722030) Homepage Journal
      They already exist. RIPEMD-160 is tried and tested and seems secure, or at the more experimental stage there's Whirlpool.
    • No algorithm is unbreakable.

      You'll always be upgrading methods to stay ahead of computing power.

      Fortunately, it's not that hard to do.
      • Well, it all depends. Catastrophe didn't happen with DES because there was an early warning and noone used it for serious stuff by that time. With SHA-1 however, the warning came a little later and the shift will be a bit more painful as a lot of things are using it, although not impossible and not a catastrophe neither.
    • Re:This is big... (Score:2, Interesting)

      by Anonymous Coward
      SHA-256 only postpones the problem...

      Well, every new development only postpones the problem. Most secret information is only valuable if it is relatively recent, so "postponing" is usually good enough.

      However, if you want to encrypt something and have it unbreakable indefinitely, you're out of luck as far as I know: the typical security argument cryptographers use is "well, if you can break our encryption, you can factor in polytime." But quantum computers can factor in polytime (and who knows what els
      • I think my point needs a bit of clarification. My point was that by saying postponing i mean that there is a higher possibility that the current research can be applied to SHA-256 soon aswell, for example breaking it in a year or a half.

        Scneier mentioned that he thought in last september SHA-1 will be broken, just not that it will be broken this soon.
      • Re:This is big... (Score:2, Interesting)

        by Riddlefox ( 798679 )
        Factoring in polynomial time is important in public key algorithms. Properly designed secret key algorithms with a key-size of 256 bits or more are unlikely to be broken even by a quantum computer (this is per Zimmerman's introduction to PGP, though he does note that history has a tendancy to make notions like this "amusingly quaint.") Grover's algorithm [arxiv.org], as far as I know, is the quantum-computing algorithm for searching. However, this algorithm effectively reduces the keyspace by half. A 128-bit symmet
  • Aren't these rarely isolated incidents?

    Isn't the probability of discovering further compromises by widespread cryptanalysis of this discovery extremely high?

  • 56 Hours? (Score:3, Informative)

    by n0dalus ( 807994 ) on Saturday February 19, 2005 @10:54AM (#11722063) Journal
    Using a modified DES Cracker, for the small sum of up to $38M, SHA-1 can be broken in 56 hours, with current computing power.

    Is that assuming that that the collision will be found on the last (or in this case, 590,295,810,358,705,651,712nd time) try?
    Because statistically it's just as likely you will find a collision on the first try as you are on the last try.
    • The same is true of brute force, just with a larger set of possible data
    • Crypto custom... (Score:3, Informative)

      by abulafia ( 7826 )
      is to speak of averages. So, it is likely that 56 hours is the time to search half the keyspace on such a machine, as over a large number of uses, that will be the average time required per use.
      • Re:Crypto custom... (Score:5, Informative)

        by Qzukk ( 229616 ) on Saturday February 19, 2005 @01:31PM (#11723040) Journal
        SHA-1 isn't about keys, or keyspaces. This attack is about finding two messages that hash to the same SHA-1 hash.

        It takes roughly 56 hours to go from a message of
        Please transfer $1,000,000 from account 123456789 to account 987654321
        which hashes to 0xAABBCCDD11223344, to a message of
        Please transfer $1,000,000 from account 123456789 to account 555555555 Its a nice sunny day please pardon the line noise Ab29!jqMV3o$2__#%#992mx...w,ea@L@L
        whichh also hashes to 0xAABBCCDD11223344, which means that it would have an identical signature, meaning that the original signature would validate the fake message.

        Personally its not the huge end-of-the-world scenario everyone thinks it is. It would probably take tens of thousands of years for this machine to output a well-formatted message that had a hash collision and could not be trivially discarded as gibberish.
    • Actually, I think you are pretty much guaranteed to find a collision on the last try. (Assuming you stop when you find it, that is)
  • The True Deadline (Score:4, Interesting)

    by AaronBaker2000 ( 480581 ) on Saturday February 19, 2005 @10:54AM (#11722064) Homepage
    It costs $38M to crack SHA-1 now. According to Moore's law, this will be cut by 25% every 3 years.

    The cost of cracking SHA-1 in...

    3 Years - $9.5 Million
    6 Years - $2.3 Million
    9 Years - $600,000
    12 Years - $150,000
    15 Years - $37,000
    18 Years - $9,000
    21 Years - $2,500

    • by JamesD_UK ( 721413 ) on Saturday February 19, 2005 @11:08AM (#11722131) Homepage
      Moore predicted that the number of transistors per integrated circuit would double every eighteen months, not that the cost of computing would halve every eighteen months. More strictly speaking it's corollary that some people draw from Moore's law.
      • For problems that can be decomposed and run in parallel, you can always use those extra transistors to make more processors (or more cores per processor). I assume checking billions of crypto keys can be done in parallel.
      • In this case I think the OP's post is accurate for first little while. As more and more SHA-1 breaking machines can be built on each chip, the size of the order will decrease. It'll decrease until the size of the order is too small for anyone to bother with (so it'll never reach $2500).
  • by Temporal ( 96070 ) on Saturday February 19, 2005 @10:56AM (#11722076) Journal
    So someone with $36 million to throw around can, in 56 hours, produce two random messages with the same SHA-1.

    Great.

    So, presumably, this devious (and very rich) hacker might produce the following two messages:
    "bma p3 rjphta,-9p.u2#H50982u.yha,cp. hxasnip"
    and
    "BUEQXBBX2 jma93#9g5xbaida htuEXOAhkra1255,y"

    And then, of course, he'd somehow trick me into signing "bma p3 rjphta,-9p.u2#H50982u.yha,cp. hxasnip". Because I sign random pieces of gibberish all the time, if asked. And then, having done this, he could go around claiming that I had actually signed "BUEQXBBX2 jma93#9g5xbaida htuEXOAhkra1255,y".

    OH NO! ::cough::

    Sure. Moving to SHA-256 is all well and good. But, frankly, I think these reports are horribly overblown. Crypto geeks are jumping up and down with their hair on fire (just like George Tenet!) because their perfect algorithm is slighly less perfect in a way that doesn't have any real practical meaning in most situations.

    Meanwhile, there are real security problems out there in the form of poorly written software and poorly administered systems. Please, please do not spend your time rewriting your software to use SHA-256 when you could be patching real security holes. Leave SHA-256 until you have nothing better to do.
    • Ummm. No. It is because given any string, I can produce another string with the same hash faster.

      And yes you do sign gibberish...It is called keys, which are used for encrypted communication. Now I can produce the key with the same hash as your key faster, and (depending on session speed) I can substitute my key for your key.

      Now -- all this only means that I can do it about 2048 times faster...not by much, and assuming there are no other weaknesses...the sha-1 hash continues to be pretty good. The increas
      • The increase in computing power makes all hashes absolete eventually, and this change only means that SHA-1 will be absolete faster.

        Obsolutely right!
      • Ummm. No. It is because given any string, I can produce another string with the same hash faster.
        Eh? That contradicts what I've heard, which is that only carefully chosen numbers have the easy-to-find collisions.

        Meaning that to more easily attack my encryption key, you'd have to be in a position to choose it in the first place.

      • It is because given any string, I can produce another string with the same hash faster.

        No, that would be a pre-image attack. This is a collision attack. To perform it, the attacker needs to be able to choose both strings.

        • You are probably right...the 2^69 confused me.

          Oh I see. So this means that I can generate a colliding pair in 2^69, but I have to generate pairs of strings without fixing any of them. Interestingly enough...if the hash is perfect then the collision attack and pre-image attack would require the same computational complexity....which makes me think is usually not the case given any hash function in P memory and time.

          Obviously it is the case in the perfect hash function...but the only perfect hash that I can
          • by swillden ( 191260 ) * <shawn-ds@willden.org> on Saturday February 19, 2005 @12:57PM (#11722846) Journal

            So this means that I can generate a colliding pair in 2^69, but I have to generate pairs of strings without fixing any of them.

            That's it exactly. In the case of an unbroken hash that outputs 160-bit blocks like SHA-1, you'd need to generate 2^80 hashes, on average to find a collision. The reason this is 2^80 and not 2^159th is the effect of the birthday paradox [wikipedia.org].

            Interestingly enough...if the hash is perfect then the collision attack and pre-image attack would require the same computational complexity....which makes me think is usually not the case given any hash function in P memory and time.

            That's a very interesting statement. What do you mean by "perfect" and can you elaborate on how a hash that is "perfect" has the same collision and pre-image attack complexity? It seems to me that a "perfect" (my definition) hash that produces n-bit outputs should have no pre-image attack that has better than 2^(n-1) complexity, whereas the birthday paradox will allow a collision attack with approximately 2^(n/2) complexity (that's a really rough approximation, but it's close enough for most purposes).

            Obviously it is the case in the perfect hash function...but the only perfect hash that I can think of requires exponential space.

            Not so obvious to me, unfortunately, but it could be that I'm just slow. Not an infrequent occurrence, unfortunately :-/

            What's the perfect hash function you're thinking of?

      • Ummm. No. It is because given any string, I can produce another string with the same hash faster.

        And yes you do sign gibberish...It is called keys, which are used for encrypted communication. Now I can produce the key with the same hash as your key faster, and (depending on session speed) I can substitute my key for your key.

        Now -- all this only means that I can do it about 2048 times faster [...]

        Please clarify something for me before I panic. You say the attack is 2048 times faster. I gather you get

    • by bcrowell ( 177657 ) on Saturday February 19, 2005 @12:17PM (#11722576) Homepage
      So, presumably, this devious (and very rich) hacker might produce the following two messages: "bma p3 rjphta,-9p.u2#H50982u.yha,cp. hxasnip" and "BUEQXBBX2 jma93#9g5xbaida htuEXOAhkra1255,y"

      It might not be that much harder to generate a collision like this:

      • I, John Smith, agree to sell my coin collection to Fred Jones for $10. -- JonesCo internal business form bma p3 rjphta,-9p.u2#H50982u.yha,cp. hxasnip
      and
      • I, John Smith, agree to sell my nubile teenage daughter to Fred Jones for $10. JonesCo internal business form BUEQXBBX2 jma93#9g5xbaida htuEXOAhkra1255,y
      And if cryptographers are finding stronger and stronger attacks against SHA1, it's foolish to assume the attacks won't get any stronger.
  • Here is the paper!! (Score:3, Informative)

    by rbarreira ( 836272 ) on Saturday February 19, 2005 @11:05AM (#11722121) Homepage
  • whirlpool anyone? (Score:3, Informative)

    by ubiquitin ( 28396 ) * on Saturday February 19, 2005 @11:16AM (#11722163) Homepage Journal
    SHA-2 in 256 and 512 bit flavors isn't the only alternative folks. Among other nifty hashes, there's whirlpool: Linux 2.6 kernel crypto API entry for whirlpool [linuxhq.com] and a page with whirlpool details [terra.com.br].
  • by ites ( 600337 ) on Saturday February 19, 2005 @11:24AM (#11722198) Journal
    All crypto algorithms age, and even if the news of SHA-1's death is somewhat dramaticised by people who make their living from security work, it's important to see _all_ crypto algorithms as temporary shims.

    That is why anyone developing new protocols and products that rely on security should use SASL, which abstracts the crypto layers in such a way that it's easy to change them over time.

    SASL is an IETF standard and there are open source implementations like Cyrus.
  • by MLopat ( 848735 ) on Saturday February 19, 2005 @11:32AM (#11722254) Homepage
    Having worked in the crypto field, I thought I would take some time to clear up a few misconceptions. First off, the results of this paper in no way compromise the security of email or other data encrypted with algorithms that use this hash. As an extension of Moore's law prevails, these characteristics of any hash function are bound to be discovered. However, with that said, it is important to realize that this new discovery in mathematics allows us to move forward with hash technology to develop better algorithms.

    Hash algorithms are one of the least understood principles in cryptography. The established mathematics around them is contemporarily vague, but under constant research. Therefore, anytime a new publication illustrates a flaw, technique, weakness, etc. we should be pleased that our understanding has grown and that a new, more advanced algorithm can be created with the knowledge gained.

    This discovery is a not something to panic about, but rather an achievement that will bring about newer, stronger encryption technology.
  • If you post the same story enough times, eventualy your'll get the right combination and break it :)

    --
    There is no such thing as duplication, only verification, alas alot verify the stupid.
    --
  • As I have not installed linux or solaris for over a year now, so I cannot comment on either of them... But I do know that all the *BSD's, at least, have native support for Blowfish (everything from user passwords to SSH, apache, java, etc).

    Having found this [resist.ca] and other comparisons, I see little reason to use SHA (any of the versions of it) for anything. Blowfish (BFS) has military grade strength and is insanely fast to compute. While the newer versions of SHA (-256 & -512) might be significantly mor
    • Hmm...but SHA is a hashing (i.e. one way) algorithm, and Blowfish is an encryption (i.e. bidirectional) algorithm. (For more on this, see the page you actually linked to.)

      So you don't use SHA-1 as an encryption algorithm for stuff like SSH, etc., because, well, you can't. Well, you can encrypt, but good luck decrypting :-)

      But you might use SHA-1 to generate crypto keys from plaintext data (e.g. passwords) for use by an encryption algorithm. So 'switching to Blowfish' won't help - you need to switch t

  • do not use moores law [slashdot.org]

    Please do not mention moores law. Why not stop all research into CPU core technology, and just wait for my CPU in my computer to double its speed every 18 months.

    If anything it is an insult to those minds who give us the CPU power that we have. It is taking it for granted, that these people develop the crazy shit they do.

    And I hear people using it far too much, please do not use moores law [slashdot.org].
  • by Shanep ( 68243 ) on Sunday February 20, 2005 @04:50AM (#11727610) Homepage
    The findings are that SHA-1 is not collision free

    NO hash algorithm which is capable of reducing an arbitrary number of bits to a smaller message digest, is ever going to be collision free when the input is larger than the digest. Ever.

    The difficulty is normally in finding a collision, whether through brute force or algorithmically.

    It would be possible to design a hash algorithm to have no collisions with input of a length smaller than or equal to the message digest. But that is of pretty limited use when we're talking about lengths like 160 bits.

HOLY MACRO!

Working...