Slashdot Mirror


NIST Announces Round 1 Candidates For SHA-3 Competition

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?"

2 of 125 comments (clear)

  1. Re:Popular wisdom has a very good reason... by jd · · Score: 0, Offtopic
    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-engineered software either uses defines or, if it's really good, negotiates. Bad software, and pandering to it, is why Windows has accumulated more crud than a farmyard without the benefit of being able to use it to fertilize.

    (Despite conventional wisdom, Windows is not popular because it supports bad software. It's popular because it's pre-installed and has enough good software that people can ignore all the bad crap. If Linux were to insist on supporting all of the bad crap written for it - do YOU use a.out binaries still? - for the indefinite future, it would not improve its popularity. If anything, it would risk the popularity it has gained and its forward momentum, all achieved by willingly sacrificing the bad from the past (with the exception of X11) in favour of developing the good for the future.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  2. Re:Why can't we mod down submitters? by jd · · Score: 0, Offtopic
    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 industries, take a squint at Formula 1, where those who don't move forwards go backwards. The designs are barely tested, have no peer-review, are infinitely more complex than a one-way function and are punished far more severely than any two or three rounds of testing by NIST can achieve. True, many break. But if nobody drove them at all in case they would break, they'd be racing nothing more advanced than a horse and cart.

    And like I said, who said anything about MY tech skills? I happen to like the tech skills of the guys who wrote Skein and MD6, and I happen to know that most modular crypto libraries out there take modules with nearly identical APIs to the sample implementations. What the F do =my= tech skills have to do with this? A blind onion could make the marginal changes needed. If you can't out-program a vegetable, that's hardly my problem, is it?

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)