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