Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Encryption Security Technology

NIST Announces Round 1 Candidates For SHA-3 Competition 125

jd writes "NIST has announced the round 1 candidates for the Cryptographic Hash Algorithm Challenge. Of the 64 who submitted entries, 51 were accepted. Of those, in mere days, one has been definitely broken, and three others are believed to have been. At this rate, it won't take the couple of years NIST was reckoning to whittle down the field to just one or two. (In comparison, the European Union version, NESSIE, received just one cryptographic hash function for its contest. One has to wonder if NIST and the crypto experts are so concerned about being overwhelmed with work for this current contest, why they all but ignored the European effort. A self-inflicted wound might hurt, but it's still self-inflicted.) Popular wisdom has it that no product will have any support for any of these algorithms for years — if ever. Of course, popular wisdom is ignoring all Open Source projects that support cryptography (including the Linux kernel) which could add support for any of these tomorrow. Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today? Wouldn't it just be geekier to have passwords in Blue Midnight Wish or SANDstorm rather than boring old MD5, even if it makes no practical difference whatsoever?"
This discussion has been archived. No new comments can be posted.

NIST Announces Round 1 Candidates For SHA-3 Competition

Comments Filter:
  • by the eric conspiracy ( 20178 ) on Sunday December 21, 2008 @09:38AM (#26191079)

    What is the point if they only got one submission for the Hash contest? Doesn't that make it the automatic winner?

    Surely you want to do better than have to pick from more than one choice.

    And yes it will take years to pick the winner. Duh. You don't want to just throw something out there that will get broken immediately.

    • by Tony Hoyle ( 11698 ) * <tmh@nodomain.org> on Sunday December 21, 2008 @09:48AM (#26191123) Homepage

      What is the point if they only got one submission for the Hash contest? Doesn't that make it the automatic winner?

      Not if it isn't shown to be secure. If needs to be tested first.. it may be they have no winner.

      • by spud603 ( 832173 ) on Sunday December 21, 2008 @10:28AM (#26191349)

        Not if it isn't shown to be secure

        Rather: Not if it is shown to be insecure.

        • by ikegami ( 793066 )
          The grandparent had it right. The starting position in security should be an assumption of insecurity.
          • by Phroggy ( 441 ) <slashdot3@NOsPaM.phroggy.com> on Sunday December 21, 2008 @02:22PM (#26192887) Homepage

            The grandparent had it right. The starting position in security should be an assumption of insecurity.

            Yes, but you can't prove that it's secure, only that it's not.

            • by Anpheus ( 908711 ) on Sunday December 21, 2008 @02:31PM (#26192937)

              You can prove its security against a number of known types of attacks, which is how there's already 1, up to 4 disqualified hashing algorithms in the NIST competition.

              • But that still doesn't prove that it is 100% secure, only that it can withstand those kinds of attacks.

                Think scientific theories. You can perform individual tests to see if the theory holds true, but you can never say with 100% certainty that something is true.
                • by Anpheus ( 908711 )

                  I don't get why people misread what I'm saying. There are a number of established cryptographic techniques for 'breaking' an encryption or hashing algorithm. A tentative first step to finding a new algorithm is to, duh, make sure it's resistant to all the old techniques.

                  -I- never said you could prove the security of anything other than a one time pad, everyone loves to infer that though.

              • by RichiH ( 749257 )

                To quote grandparent: "Yes, but you can't prove that it's secure, only that it's not."

            • It's Schrodinger's cat: you might prove it secure by exhaustively mapping its function over the whole input range and then assessing the proximity of results and the psuedo-randomness of the mapping. The problem with that being that you then know how to recover any original text from a given encrypted result...

    • by PolygamousRanchKid ( 1290638 ) on Sunday December 21, 2008 @10:30AM (#26191359)

      What is the point if they only got one submission for the Hash contest?

      Europe's top contenders in the hash competition were devastated by some new laws in Amsterdam, banning whores and space-cake cafes: http://news.ninemsn.com.au/article.aspx?id=683353 [ninemsn.com.au]

      Well, duh, do you think people travel there to look at the wooden shoes and windmills? What have their politicians been smoking?

      And yes it will take years to pick the winner.

      If the stuff is good, and the judges supply of Doritos hold out, it could take decades.

  • by rtfa-troll ( 1340807 ) on Sunday December 21, 2008 @09:41AM (#26191093)

    Actually, it's probably much better to have MD5 which is known broken in understood ways, than Jo3#a$# which is broken but we don't know how, where and why. There are fairly simple rules for MD5 (start phasing out now; only use in situations where you in some way control the input, not your adversary) which make it possible to use in a relatively safe way. If you don't know what way the hash is broken you don't know how to avoid those problems. Having said that, SHA256 should probably be considered the minimum for a temporarily secure system with a lifetime limited until something better has been available and tested. As Mr Schneier says "attacks only get better; they never get worse".

    It's also not a surprise that some hashes got broken. There are many entries and they come from all types of cryptographer from teenager to aged expert; from unknown to known mostly by initials (e.g. A, S or R). There was not much hope that all of them would be of good quality.

    • by jd ( 1658 )
      All hash functions, no matter how carefully reviewed by however many experts, are broken in unknown ways. The winner of the SHA-3 contest will be broken in unknown ways. It won't stop you using it once it's circulated and part of the "standard". You will and you know you will. So your usage has nothing to do with whether people know where the breaks are, it has to do only with whether it is circulated. If Joe Cracker is so good at breaking hashes that we need fear for the safety of Skein or MD6, then I woul
  • by CajunArson ( 465943 ) on Sunday December 21, 2008 @10:08AM (#26191215) Journal

    Wouldn't it just be geekier to have passwords in Blue Midnight Wish or SANDstorm rather than boring old MD5, even if it makes no practical difference whatsoever?

    s/geekier/stupid and irresponsible

    Let me guess, the submitter likes to enable all the useless bling effects on Compiz but never gets any work done, and has racing stripes on his Civic....

    I went to Carnegie Mellon and took classes from a bunch of professors who were all freakin' geniuses and here is the second most important lesson I learned about cryptography: NEVER DO IT YOURSELF. And a corollary to that is never use a cryptographic system someone else cooked up until it has been through the vigorous peer review that these hash functions will go through. This was an important lesson to a bunch of egotistical CMU students, and I hope the ones who were actually smart listened. (The first most important lesson is an old one: if you think cryptography is the solution to all your security problems, you don't understand cryptography or your security problems).

      "Whaa! But the ciphers we have now are already broken!!" The current hash functions that are "broken" like SHA-1 are not trivially broken, but broken in a sense that in some scenarios might make it somewhat easier to conduct either a pre-image attack (useful if you know somebody's password hash and want to make a password that will hit the same hash) or a collision attack (useful in some cases where you are trying to forge a messsage to match a digital signature.... but if the fake message has to contain lots of garbage bytes even a successful collision might not pass the smell test). "Somewhat Easier" does not mean you can do it on your iPhone, it just means that it might take a supercomputer 100 years instead of the heat death of the universe to do it. This is still very important, but it is a world apart from an algorithm that has never been tested... those could be blown wide open and cracked almost instantly with trivial computing power. To use a bad car analogy, just because a seat belt won't save your life in every car accident doesn't mean it's just as safe to strap plastic explosives to your gas tank and hook them up to a mercury switch detonator.

        As for "open source" making these cryptographic models available quickly, I wasn't aware that text editors froze up and stopped you from writing code if it wasn't going to be open source. The reason commercial vendors won't jump on a new cryptographic protocol before they are validated is that their customers would (rightly) go ballistic and their credibility would be smashed. Fortunately for all of us the leaders of the open source community have a little more sense that you and you won't see any of these hashes in the Linux kernel or OpenSSL until they are at least in the final rounds of competition and there is some evidence that they have value. OSS has the advantage that its software implementation can be publicly validated and peer reviewed, but having your code opened up to the world is actually much MORE dangerous if you are just screwing around because you think a hash function has a badass sounding name. I'm glad Torvalds is in charge of Linux and not "jd".

    • Let me guess, the submitter likes to enable all the useless bling effects on Compiz but never gets any work done, and has racing stripes on his Civic....

      Well said. Also the rest of your post is spot on. I'm going for the 'ignorantsummary' tag myself.

      • Re: (Score:1, Insightful)

        by Anonymous Coward

        Well said. Also the rest of your post is spot on. I'm going for the 'ignorantsummary' tag myself.

        It needs a !encryption tag too.

      • by jd ( 1658 )
        If the rest of his post is so well-said (such as wondering why they can't mod down submissions), why am I able to go to the Firehose and, well, mod down submissions? Far as I'm concerned, if his argument is so easily broken, it can't be treated as the least bit reliable. True, you will find "bling" on my computer. It'll be in the form of kernel patches I've ported or "adjusted". Assuming you consider "bling" to mean anything that isn't strictly necessary but is great fun to exercise and which sometimes actu
    • by Ant P. ( 974313 )

      That's the biggest WHOOSH I've ever seen on Slashdot.

    • Re: (Score:2, Funny)

      Comment removed based on user account deletion
    • > As for "open source" making these cryptographic models available quickly,
      > I wasn't aware that text editors froze up and stopped you from writing
      > code if it wasn't going to be open source.

      You know, you were making some nice points, and here all you do is hurt your credibility. You know exactly what he was saying, and he was right.

    • The whole point of the contest is to give all the candidates testing and scrutiny. Sure, I would currently choose one of the SHA-2 family (256, 384 or 512) for any current thing I was doing where it mattered. But I fully expect that in 2-5 years time I will instead choose one of the algorithms that was recently submitted to NIST.

      I am disappointed though to not see Whirlpool [wikipedia.org] in the list.

      And MD5 is just plain out broken, and there are alternatives that are better in every respect. If I had my way the algor

    • Re: (Score:2, Insightful)

      by jd ( 1658 )
      1. You cannot "lead" from behind. Ergo, you cannot both be a leader AND and follower at the same time. If you are waiting until someone else tells you it's ok, you're a follower.
      2. In a race, the ones who look behind them fall over. Those who look ahead at least finish (a key requirement in winning).
      3. Skein was hardly designed by Joe Punk. Neither was MD6. Both have sample code. So who is doing all this DIY stuff you speak of?
      4. You can either know you are safe or you can be ahead of the game. You can't have both,
      • by Anonymous Coward

        You seem to be of the same type of people the GP was attacking. So you can either know you are safe or ahead of the game... For what are you using cryptography again? Showing off your tech or securing your data?

        • Re: (Score:1, Offtopic)

          by jd ( 1658 )
          The Victorian "thief lock" is well-tested, has been around for ages, is well understood by experts, and is used by exactly no-one to secure their belongings. The high-end, high-quality locks that security experts rave about are, by comparison, barely tested by anyone, have had minimal serious testing, are probably not understood by many experts owing to IP laws, and are used by people serious about keeping their belongings. Which camp did you say you fall into, again?

          If you prefer to look at other industr

          • ...I happen to know that most modular crypto libraries out there take modules with nearly identical APIs to the sample implementations. ... A blind onion could make the marginal changes needed.

            The marginal changes need to... what? Create a new crypto module?
            Sorry for not understanding. I'm a blind onion. :(

            • by jd ( 1658 )
              The submitted example code for this contest uses a standardized API that is 99.99% the same as that used by mhash, libgcrypt and others. Likewise, submissions for the AES contest used a standardized API that was 99.99% the same as used by mcrypt, libgcrypt and others. The differences largely consist of the prefix used on the function names and restrictions on the naming of global variables. Search-and-replace should be almost sufficient. Adding some means of registering the function with the library (usuall
      • What a load of empty, bullshit rhetoric. "In a race, the ones who look behind them fall over. Those who look ahead at least finish (a key requirement in winning)."? Fuck off.

  • Hashes in general (Score:3, Informative)

    by zysus ( 123604 ) on Sunday December 21, 2008 @10:43AM (#26191433) Homepage

    I hate to state the obvious, but a hash by nature is breakable. You are (typically) distilling a large number of unique bits down to a smaller number of bits.

    Of course there will be more than one set of inputs that generate the same output.

    Its more an issue of:
    1. How hard it is to find colliding inputs.
    2. What the hash is used for.

    Passwords typically generate more bits, so different rules apply.

    • its if those bits that come out have a truely random distrobution which being unpredictible. The outputs of hash functions are weakened from theoretical (perfect) (apparent) entropy by a need to do things fast. Distrobutions are not perfectly distrobuted and randomness is removed through the passes.

      But both of these things can be completely solved with even crappy systems simply by using larger keys. The most import thing is a (CPU+RAM/bit of entropy). If want something secure do a triple blowfish-whirlpool

    • by Goaway ( 82658 )

      I hate to state the obvious

      Then why do you do it?

    • by jd ( 1658 )
      You are absolutely correct, which means that the difference between one hash that is currently secure because nobody has found any weaknesses and another which also has no currently-known weaknesses is one of confidence that a weakness won't be found soon. SHA-1 has vulnerabilities which (should) reduce the confidence levels. MD5 is considered completely broken within such things as validating a file is untampered with. But SHA-1 is likely used for classified data (which it should no longer be, it's no long
  • Look at MD6 (Score:5, Informative)

    by ivoras ( 455934 ) <ivoras&fer,hr> on Sunday December 21, 2008 @10:55AM (#26191517) Homepage

    MD6 (similarity in name to MD5 is entirely intentional) looks very interesting:

    • Security: MD6 is by design very conservative. We aim for provable security whenever possible; we provide reduction proofs for the security of the MD6 mode of operation, and prove that standard differential attacks against the compression function are less efficient than birthday attacks for finding collisions. We also show that when used as a MAC within NIST recommendations, the keyed version of MD6 is not vulnerable to linear cryptanalysis. The compression function and the mode of operation are each shown to be indifferentiable from a random oracle under reasonable assumptions.
    • MD6 has good efficiency: 22.4-44.1M bytes/second on a 2.4GHz Core 2 Duo laptop with 32-bit code compiled with Microsoft Visual Studio 2005 for digest sizes in the range 160-512 bits. When compiled for 64-bit operation, it runs at 61.8-120.8M bytes/second, compiled with MS VS, running on a 3.0GHz E6850 Core Duo processor.
    • MD6 works extremely well for multicore and parallel processors; we have demonstrated hash rates of over 1GB/second on one 16-core system, and over 427MB/sec on an 8-core system, both for 256-bit digests. We have also demonstrated MD6 hashing rates of 375 MB/second on a typical desktop GPU (graphics processing unit) card. We also show that MD6 runs very well on special-purpose hardware.

    While raw speed isn't great (the default single-threaded 32-bit md5sum in Linux can do 325 MB/s on a 2.4 GHz CPU) maybe its multi-core friendly design is the right way to do it right now. The original MD5 will probably not entirely disappear because of its speed.

    (OTOH if you're hashing SSL web traffic it's probably worse to have your hash bog down other CPUs that are busy with their own jobs)

    • I don't find the multi-core so useful, it's rare that I want to hash one, very large file. More often I want to hash many things, which naturally parallelises. In your SSL web traffic example, if you app isn't dealing with as many connections as it has cores, then you probably don't have to worry about performance, and if you do then you already have one compression per core.
    • I would like proofs of security to assume the availability of quantum computation. Do your proofs of security assume this?

      • by Dan Ost ( 415913 )

        I was under the impression that quantum computing was only a threat to some public key schemes (like RSA).

        Is quantum computing a threat to AES or any other popular symmetric key encryption method?

        • Yes, but not a major threat. Quantum computers allow the search time to be cut to the square root of the normal search time. This effectively halves the key length. A 256 bit key now takes only an average of 2^127 operations to find instead of 2^255.

          This isn't nearly so much of a problem though as for public key encryption schemes. For RSA, for example, quantum computing changes the time from super-polynomial but sub-exponential to being polynomial with a very low exponent.

          I would be really curious to s

    • Re:Look at MD6 (Score:4, Insightful)

      by owlstead ( 636356 ) on Sunday December 21, 2008 @03:38PM (#26193529)

      MD6 is definitely a serious contender. Its very conservative and well researched. It's main contender is probably Skein at the moment, although there are a few others to consider. MD6 is however not as fast as some contenders, not as flexible as some and its internal state is, as I believe, larger, which makes it more of a pain on embedded and smart card processors. In all this, Skein beats MD6. It's parallel design is using a typical hash tree, which can be used for many other hash methods as well, although MD6 uses it in its main operation.

    • It looks slow. (Score:3, Interesting)

      IIRC, Skein is getting about 6 cycles a byte in 512-bit mode on 64 bit platforms, which on a 2.4GHz dual core CPU would yield a theoretical 800 MB/s in a parallel tree hashing mode, 400 MB/s in standard mode. Apparently MD6 has a parallel mode also, and it's striking that both hash functions are trying to be minimalist by employing only three fundamental operations (AND, XOR, SHIFT for MD6; XOR, ADD, ROLL for Skein) and lots of rounds. It's odd that MD6 should be so much slower. Perhaps it hasn't been fu

  • Salts... (Score:3, Interesting)

    by Manip ( 656104 ) on Sunday December 21, 2008 @10:58AM (#26191539)

    In answer to - "have passwords in Blue Midnight Wish or SANDstorm rather than boring old MD5, even if it makes no practical difference whatsoever?"

    I'm going into the "no practical difference whatsoever" camp. In fact you're taking a huge risk if any of them are broken and you gain nothing that simply salting your hashes doesn't already give you.

    We know that MD5 is secure to a degree. Just salt that bad boy up so rainbow tables no longer have any impact.

    • by jd ( 1658 )
      True, a good dose of salt will improve the hashes. (But it may lead to higher blood pressure.) My concern is that the vast majority of "hackers"/crackers are either skript kiddies or macho wannabes. They can exploit known weaknesses, they can use known techniques, they can download known black hat toolkits, but they will never discover or write anything worth a damn themselves.

      If 99% of the risk comes from people with 1% of a functioning brain, it makes no sense to not take simple precautions that might (

  • by Ex-Linux-Fanboy ( 1311235 ) on Sunday December 21, 2008 @11:12AM (#26191635) Homepage Journal
    I spent a few hours the other day looking over all of the submissions; Keccak and Skein are my favorite contributions. My criteria was "does the hash generate a fixed-length output, or is the hash capable of also being used as a stream cipher".

    There are only four unbroken contributions that can generate arbitrarily long streams of numbers: Keccak [noekeon.org], LUX [tugraz.at], MeshHash [tugraz.at], and Skein [skein-hash.info]. Of these contributions, LUX and MeshHash, while not broken, already have cryptanalysis done against them that make me a little uneasy using them.

    I prefer Keccak over Skein, for the simple reason there is a bonda-fide 32-bit variant of Keccak that can run quickly on 32-bit systems. Skein is designed to run well only on 64-bit systems. Part 5.4 of the Skein paper talks about the possibility of making a 32-bit variant of Skein but that they need to come up with rotation and permutation constants, and figure out how many rounds a 32-bit Skein variant would need. I would like to see Schneier, et al (the team responsible for Skein) actually do this. Skein is more flexible that Keccak (I think threefish is the first tweakable block cipher since the somewhat broken Hasty Pudding Cipher), and is faster on 64-bit systems, but I would like to see it run on embedded and legacy systems better.
    • Re: (Score:1, Informative)

      by Anonymous Coward

      bonda-fide

      Just for your own records, the phrase you want is bona fide (lit. "In good faith.").

      I have no ability to comment on the rest of your post, though.

    • by hypersql ( 954649 ) on Sunday December 21, 2008 @12:16PM (#26192051)
      A better overview: The SHA-3 Zoo [tugraz.at]. Did you look at Edon-R [tugraz.at]? It is not be the most flexible, but it's the fastest one. Followed by Skein. I agree to what Bruce Schneier wrote [schneier.com]: sort the algorithms based on performance and features, and then focus on the top 12.
    • Re: (Score:3, Insightful)

      by ultranova ( 717540 )

      My criteria was "does the hash generate a fixed-length output, or is the hash capable of also being used as a stream cipher".

      Every hash function can be used as a stream cipher: you simply hash the password, then hash the resulting hash, and so on, and use each intermediate hash as input to a stream you then XOR the cleartext stream with to produce the ciphertext.

      Of course for this to be secure, the hashes must be undistinguishable from random strings, but I'd imagine that's a requirement for a good hash fu

      • The problem with this, of course, is that due to the Birthday Paradox, you will start creating a loop after (on average) sqrt(NUMBER_OF_POSSIBLE_HASH_OUTPUTS). For short messages, this is usually okay, but for long streams of "random" bytes, this is totally unacceptable.

        On the other hand, you could use a stream based on the following:

        hash("1"+SEED)+
        hash("2"+SEED)+
        hash("3"+SEED)+
        hash("4"+SEED)+ ...
        hash("1231142"+SEED)+
        hash("1231143"+SEED)+ ...

        assuming that your hash has a distribution indistinguishable from

        • The problem with this, of course, is that due to the Birthday Paradox, you will start creating a loop after (on average) sqrt(NUMBER_OF_POSSIBLE_HASH_OUTPUTS). For short messages, this is usually okay, but for long streams of "random" bytes, this is totally unacceptable.

          Good point. I assumed that you'd loop after 2^hashlength, but of course even that has the same problem. I guess it just goes to once again show that cryptography should be implemented by real experts :).

          How about using hash(n + previous_has

  • Here is a torrent of all 51 submissions: http://thepiratebay.org/torrent/4592403 [thepiratebay.org]

    • by jd ( 1658 )
      If NIST can get slashdotted, we have far more serious problems than just hash functions being broken and we should go back to being an agrarian culture. A far more likely outcome (and, IMHO, a better one) would be for the mailing list to explode in new members (a total of 51 + non-entering SHA3 Zoo contributors shouldn't be too hard to beat) asking totally obvious questions that weren't asked (because they were obvious) but should have been (because arguing a point is a superb way for the arguer to spot wea
  • by kscguru ( 551278 ) on Sunday December 21, 2008 @12:19PM (#26192063)

    Popular wisdom has it that no product will have any support for any of these algorithms for years â" if ever. Of course, popular wisdom is ignoring all Open Source projects that support cryptography (including the Linux kernel) which could add support for any of these tomorrow. Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today?

    It matters a lot. Say OpenSSL added all of these algorithms tomorrow. Some idiot developer (hint: go read DailyWTF) will build on top of it. OpenSSL now has to maintain backwards compatibility - so they can never take out the algorithm. A month from now, the algorithm gets broken completely. But because OpenSSL shipped with it, they can never take it back out.

    The "popular wisdom" standard for proliferating a new algorithm is not how shiny it looks at first glance. Popular wisdom waits months or years until algorithms seem good enough. MD5 (or even MD4), SHA1 - all are good enough for some purposes (generally, when attacker does not control input). And if the attacker does control the input, the only sure solution is to send the whole thing - anyone believing otherwise needs to review the meaning of the word "hash". A secure hash is merely an irreversible hash with a very low risk of collision.

    Even this article is mostly "security theater". There are very, very few uses of secure hashes where SHA1 (or even MD5, for that matter) is not good enough.

    • Re: (Score:1, Offtopic)

      by jd ( 1658 )
      Err, well, no. They can take out features, they probably have in the past and they certainly will in the future. Linux is no different. Those who wrote code assuming Intermezzo or the kernel-based devfs would always be there are, well, victims of their own folly.

      The same applies to hash functions. You have some mechanism for identifying which function you are using and then you use it. Hard-coding is for wimps and fools, and is almost always the true cause of backwards incompatibility. Correctly-engineere

  • by Argilo ( 602972 ) on Sunday December 21, 2008 @12:36PM (#26192193)

    The article is already out of date. The round 1 candidates were announced back on December 11. Since that time, 11 candidates have been broken. For the latest information, I recommend visiting the SHA-3 Zoo [tugraz.at].

    Also, the article suggests that candidates will continue to be broken quickly, but I doubt this will happen. The weak hashes will be broken quickly, but there are likely to be many strong candidates which will not be broken during the contest. Other factors (speed, simplicity, etc.) will determine the ultimate winner.

    • by jd ( 1658 )
      I dunno. From th last time NIST updated its website to the last time SHA-3 zoo updated theirs, a whole bunch more functions got broken. And as the pool dwindles, the number of crypto experts studying each function increases and the value (both of breaking the hash and in terms of PR within crypto circles) rises. Sure, it won't be linear, but I don't expect the fall-off to happen for a while yet. IF anything, the breakage might rise for a brief time as the holidays afford precious extra thinking time and a w
  • by lkcl ( 517947 ) <lkcl@lkcl.net> on Sunday December 21, 2008 @01:55PM (#26192701) Homepage

    Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today?

    does it matter? does it matter?? fuck me it fucking matters.

    example 1

    there's a type of encryption algorithm principle - the feistel cipher - see http://en.wikipedia.org/wiki/Feistel_cipher [wikipedia.org] - where you perform one simple transform function as "round 1", then for rounds 2 and 3 you do a one-way hash function, and then for round 4 you do a simple transform function.

    if the one-way has is ever broken, your encryption cipher is also broken.

    game over: any traffic that's ever been using that cipher can be decrypted.

    example 2

    your credit cards you carry around? the PIN number isn't stored on the card - but an MD5 hash of the PIN number *is* stored on the card (making replay attacks possible, believe it or not).

    if MD5 is ever cracked...

    game over: anyone can get your PIN number.

    example 3

    your peer-to-peer filesystem, your git source control system, they use one-way hashes to store an index of the data blocks. let's say that someone deliberately wants to break deployed systems, they work out what file chunks could end up being mapped to the same one-way hash...

    game over: anyone can corrupt the database or the peer-to-peer filesystem by _deliberately_ making file or file chunks write to the same block.

    i could go on with the list of examples - authentication systems that would fall over; internet bank systems that could be broken in to - we _totally_ rely on one-way hashes working correctly.

    it's important beyond _belief_ that these one-way hash functions work, so much so that i was staggered that the question even had to be asked as part of the article-announcement.

    • it's important beyond _belief_ that these one-way hash functions work, so much so that i was staggered that the question even had to be asked as part of the article-announcement.

      Welcome to the world of cryptography where nitwits feel free to bandy about the most ridiculously stupid assertions because they don't actually understand what they're talking about.

      I have a theory that many geeks are so threatened by knowledge they don't have and think might require a lot of effort to acquire that they will go thr

      • Wait, you haven't figured out that Slashdot is the compression function of the cryptographic hashes of an advanced extraterrestrial race (whose projections in our reality are, well, whatever you find most amusing)?

    • Credit Card fallacy (Score:1, Informative)

      by Anonymous Coward

      example 2

      your credit cards you carry around? the PIN number isn't stored on the card - but an MD5 hash of the PIN number *is* stored on the card (making replay attacks possible, believe it or not).

      A common fallacy. The standards for PIN generation on magnetic cards were developed long before MD5 became common. The 'IBM' methods (guess who makes the security processor at the other end of the ATM links?) are based on your PIN being a hash of your account number and a bank secret key, known only to the bank and the ATM. This lets the ATM work offline but not know your personal PIN.

      Later they let your PIN be changed by also storing an 'offset' between the 'real' PIN and CSP (customer select PIN) for each

    • by jd ( 1658 )
      MD5 is effectively broken, replay attacks against debit and credit cards are commonplace (banks lose millions to it yearly), and the use of it in something as commercially sensitive as a credit card is the height of stupidity. "If" it is ever broken doesn't apply, because enough weaknesses have been established to prove conclusively that a total breakage is just a matter of time. If it hasn't already happened. I doubt organized crime or the NSA file the hashes they can break with the Hash Function Lounge.
    • by jcam2 ( 248062 )

      your credit cards you carry around? the PIN number isn't stored on the card - but an MD5 hash of the PIN number *is* stored on the card (making replay attacks possible, believe it or not).

      I sure as hell hope not! If that was the case, anyone with a card reader could brute-force your PIN in under a second by taking the MD5 hash of all 4 digit numbers, and comparing them to be hash that is supposedly on the card.

    • an MD5 hash of the PIN number *is* stored on the card (making replay attacks possible, believe it or not).

      if MD5 is ever cracked...

      game over: anyone can get your PIN number.

      Bullshit and chips. Look, there are only 10,000 possible pins, do you know how long that would take to force? Hell, a complete rainbow table is only 156k. Even if salted, do you know how long it takes to hash 10,000 4 digit numbers?

      There. Just did it. Took 0.1 seconds on my 800mhz laptop.

      Your information does not pass a basic sanity test.

      (Plus, it's debit cards which have PINs, not credit cards)

      • (Plus, it's debit cards which have PINs, not credit cards)

        Most credit cards do, or at least can, have a PIN so you can use them to withdraw cash from a cash machine (ATM). In the UK, and increasingly in the rest of the world, you now enter your PIN rather than signing a piece of paper when making purchases too.

  • Triple MD5 Anyone? (Score:3, Interesting)

    by Nom du Keyboard ( 633989 ) on Sunday December 21, 2008 @01:59PM (#26192731)
    Triple MD5 anyone? Hey it worked to extend DES!

    (Triple MD5 is is composed of the XOR of standard MD5 first byte to last byte, MD5 last byte to first byte, MD5 middle out to the ends. Faster hardware makes this feasible now.)
    • Re: (Score:3, Insightful)

      by owlstead ( 636356 )

      It is very doubtful that this is more secure, and it certainly more of a hassle. I would not want to hash a stream with a method like that.

      • Re: (Score:3, Interesting)

        by owlstead ( 636356 )

        Replying on myself here, but any algorithm that starts with encoding the hash size is bad as well, IMHO, and there are some examples of that in the SHA-3 zoo. If you have e.g. XML base 64 encoding you may not know the full length before decoding, so you cannot hash at the same time.

    • Re: (Score:3, Informative)

      Several points about this:
      -DES was never algorithmically broken--it was just designed with too small a key size. 3DES effectively doubles the key size to something reasonable. MD5, however, is actually broken--it has algorithmic weaknesses that can be exploited. Thus, it's not an analogous case.
      -We know a lot more about hash functions now than was known when MD5 was designed. From new attacks (e.g. multicollisions) to new design techniques (e.g. HAIFA), there's a lot more knowledge for cryptographers to

    • It's all you ever need
  • The fact that the OS community uses MD5 still just shows how slow it is to move to new technology. MD5 is broken, it's trivial to collide. There are free alternative hashing algorithms. Stop using MD5, stop using MD5, STOP USING MD5!
  • by RichiH ( 749257 )

    The first third of the submission is interesting, relevant and sane. The rest, especially the question, is based on so much mis-understanding of the topic at hand, I just lack the time to point all of it out. I suggest OP re-thinks the effort of switching to new _and maintaining the old_ hashes for a second or twenty. That should be a good starting point for some relevations.

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...