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 (usually a standardized function call added to the API) should do the rest. If that is too difficult for a blind onion, I suggest less of their beer and more of their pizza.

In a nutshell (or is that a C shell?), yes. There is a difference in the mental process, in addition to the conceptual difference, between an adventure like Dungeon or an online experience like Essex MUD and games like Space Invaders or Chuckie Egg. There is a difference in communication between MUD's "get all the keys except the gold one and put them in a box" (which was perfectly allowed) versus "left, right, fire". There is a difference in the entire nature and spirit between Level 9's Snowball and Attic Attack. There's an entirely different kind of rapport between you and the characters between Infocom's Deadline and ID's Quake. Writing mods for Adventure/Colossal Cave was easy. Writing mods for Pole Position was not. Computer mags circulated far more adventure writing engines than arcade game engines, resulting in far more people being able to experiment and hack their own. More people today remember Zork and do so fondly than can remember Citadel or Knight Lore, despite the fact that both titles were at least as revolutionary and as popular in their day.

Muxes, mushes, moos and MUDs are not video games, they are text adventures or text social roleplaying systems. AberMUD (and descendants) would qualify, as would anything produced via one of the open-source graphical adventure systems. Text adventures, though, are generally superior to graphical ones as they can be larger, more powerful and less constrained by technology or graphics design skill. It would be hard to make a good graphical version of Dungeon, for example, despite Dungeon being ancient. For every graphical attempt you see, a hundred Dungeon-like adventures which truly take advantage of the power of modern PCs for even greater gamescapes could be churned out. Given the choice of one so-so graphical game or a hundred truly superb text games, I'll take the hundred.

Clueful users, eh? At least I was limiting myself to the theoretically possible. Remember, 100 is the -average- IQ and I wouldn't trust anyone with an IQ that low to pick a decent bicycle lock.

I would agree with you entirely. One of the few non-tangibles that really can produce returns is good quality education, as well-educated employers and employees should (emphasis on should) make better decisions, generate less waste and have a better understanding of what they are doing, all three of which should (again emphasis on should) increase the desirability and usefulness of what they produce and decrease the overheads of producing it. In other words, even though it is intangible in itself, it should directly impact that which is tangible.

The intangibles you note, such as shares in companies, where the majority must lose if anyone is to gain, are not ultimately useful. They have a short-term benefit, in that companies can sell this imaginary stock in exchange for a loan they couldn't get from a bank, but if the company is successful, the loan is going to be at an indeterminate interest rate that is potentially far higher than inflation, so even there they must lose. Only the extremely wealthy professional gamblers, err, investors, can win. And a lot of their "winnings" comes from gambling on the "dogs" - stocks in companies that are known to be corrupt and/or otherwise acting illegally in order to make money faster - as their share values tend to rise the fastest, at least until they're busted. Don't imagine for a moment that the investors can't spot a shady deal like Enron. They only invested in things like that because it was so dodgy. They complained not because it was dodgy, but because they got too greedy and stayed in too long.

Greed is also why the housing market collapsed, why the oil market collapsed and why the bailouts are likely to fail. (AP's reporting that banks and investment companies getting bailout money have been giving huge bonuses to management and letting said managers use their corporate jets for personal use. Not exactly signs of people looking for ways to cut back on the wastage they cause.) Unfortunately, you can't really make greed a crime, no matter how much it does serious GBH to society. However, the greedy stick together and the most greedy are usually the ones who are criminals, so if Government watchdogs wanted to catch the evil guys before they bring down civilization, they probably could. The fact that they don't (and usually aid said evil guys along the way) convinces me that responsibility doesn't alter human nature a whole lot.

Defeating botnets is possible in theory (you need passive fingerprinting and end-system auditing capabilities at a lower level than the botnets, both of which are entirely possible). Defeating botnets is likely neither practical (the network needed to perform counter-intrusion measures would need to be double plus one the size of the botnet) nor legal (SIGINT methodologies may be ok for the NSA or GCHQ, and then with strict qualifiers, but they are not considered ok for Joe Public under any circumstances).

You'd also need serious big iron, physical access to most of the tier 1 gateways, more money than God, more signals intelligence experts than the NSA, and more firepower than the Russian mafia. Again, nothing that is technically impossible, just very very improbable. But so long as you can generate finite levels of improbability, you should be fine.

Their code review seems to concentrate on external attacks. They have expressly derided mandatory access controls, for example, on the grounds that you've got to trust your users or you're already lost. So, OpenBSD is actually more likely to be vulnerable to such attacks than an OS with weaker reviews but superior access controls, such as Linux with the RBACS or GrSecurity patches in place. Thus, if anyone is using OpenBSD, they'd damn well better be using strong authentication.

(OpenBSD has the best strong authentication of any OS on the planet, and the best security from external attacks of any OS on the planet, but cliques of any kind are notoriously blind to any problem outside of their special interest and OpenBSD is no exception. Which is why they caught a rollicking from Slashdot when it came to failing to patch their PRNG after defects were found in the *BSD family of PRNGs. It's why you should never, ever trust a group - however good - to be good at everything.)

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 actually leads to performance or security improvements. Remember, improvement is not "necessary", but I think nice to have and I don't give a rat's arse if that means digging through obscure work that has never seen the LKML, never mind actual peer-review. I'm quite capable of reviewing source code myself and don't need your help to do so. In fact, given how many broken packages I've found in mainstream distributions, I'd rather review source-code myself than take anyone else's word for it. I may not be a coder guru, but I trust my ability to test and debug software far more than I'll ever trust the incompetents who write and fail to test the majority of code (both Open Source and proprietary) that is out there. I may not be the best, but I'm better than than that. A dead haddock could write better code than some of the stuff I've endured, so if I wouldn't trust that, why should I trust you?

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 weaknesses in their own argument). We can then dispense with the more blatantly flawed algorithms far faster and far more reliably than by having a clique studying them over coffee breaks. (Professors teach first, do paid research second so that they can afford to feed their family, and do REAL research when no-one's looking. That's why so little real innovation ever happens, except by "accident", for which you should read that the research notes were sold to the CEO over a liquid lunch in exchange for immunity for the crime of thinking and a christmas bonus).

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 longer NIST-approved for such stuff) and MD5 is used for P2P (despite making it trivial for people to poison the share pools in undetectable ways).

This is, according to the hard-boiled cynics who have posted here, a better situation than using Skein and MD6. In the military, quite possibly. SHA-512 and Whirlpool are the sensible choices there, but that always supposes they are sensible. They'd also be good for any other operation, though Whirlpool is a little slow for SSL. Still, I'd rather a page took a few tenths of a second longer to load (given that the variance is already much longer) than have credit card data in the hands of any skript kiddie with the latest black hat toolkits.

But if those two existing "trusted" hashes aren't good enough for you, Skein and MD6 would offer you better security today - unproven as they are - than MD4 or MD5 could hope to do. Same as an unproven (but quite likely good) car will offer you better protection than a rusted-up wreck with leaky fuel tank. Sure, the wreck has been tested in crashes. Sure, it's been around longer and inspected by more people. It's also a write-off and I don't consider write-offs acceptable no matter how many eyes have inspected it.

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 whole bunch of extra CPU time.

(CPU time? Sure. No better way to look for relationships between inputs and output when changing inputs in predictable ways than to have a computer churn through input rules and output rules. Humans are great at analyzing the algebra which, despite having theorum solvers, computers suck at, but humans are horrible at tedious, repetitious tasks, and inobvious relationship detection often requires a lot of tedious, repetitious examining of raw data.)

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?

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 would have thought the sooner we can get Joe Cracker onto the task, the better off we will all be. The more eyes, the better, right? And if Joe Cracker is as lazy and incompetent as I suspect, then they're not this Big Awful Threat in the first place. You win, both ways. Using what is broken, especially if you know how and why, is like putting mission-critical data on an unfirewalled Windows box and advertising the version. You know how it's broken - and so does everyone else. This gains you what?

True enough, but by the same token, the inverse of a hash can then be considered any synonym if you only need one of the possible inputs to generate the same output. If a hash is badly broken, then it may be possible to algorithmically produce an infinite series of synonyms given some seed value that is one of those synonyms. If it is horribly horribly beyond broken, you can also show that there are no synonyms that are not in that series.

At present, there are methods by which, given one synonym, it is possible to produce any number of other synonyms. From this, it is necessarily true that MD5 is capable of being badly broken even if it is still extremely hard to produce the synonym in the first place. You've X-Rayed this apple and it has a core that isn't just rotten, the bacteria and fungi have evolved an entire civilization and are busy in a reality TV ratings war. Continual use of MD5 is simply biting into the apple on the grounds that the rot hasn't reached the surface yet.