In a recession, managers will be even more eager to have nothing to be blameable over. Remember, underlings get sacked first. If they go with Microsoft, the managers will feel reasonably safe, even if it drives the companies under. They will be paid the longest and will be the most likely to be re-hired quickly. Going with Open Source will be seen as taking a risk, something that in risk-averse times will not be looked on favourably even if it DID save the company's bacon.
I see the recession as a time when views will become far more entrenched in existing companies. Start-ups may be willing to go with OSS, as they need to cut costs to a minimum and they don't have shareholders to placate, but expect extreme conservatism to reign supreme. At least for the first half of the recession. After that, some of the brain-dead companies will also be financially dead, and more dynamic companies may well be profiting from their early risks. But that's a year away at best. 2009 will not be a good year for OSS in business, though 2010 might well be.
A "perfect" cryptographic hash must meet three criteria:
a) The best herustic for determining an input which will produce the same hash as a specific target input will require as many steps on average as brute-forcing. (ie: the probability of getting a collision is the same whether you are using a programmatic solution or guessing.)
b) If inputs A, A' and A'' produce the same output, where A and A' are known, the best herustic for determining A'' will remain no better than one that brute-forces.
c) If inputs A and A' produce the same output as each other, inputs B and B' likewise produce the same output as each other, and so on for some statistically-significant number of distinct outputs, the outputs will follow a random distribution.
In other words, the apparent strength of the hash is the actual strength of the hash, no matter how much information has been obtained (either by analysis or by chance). There are two "obvious" properties which are necessary but not in themselves sufficient to produce those criteria. These properties are:
a) The change in output in relation to a given change in input will follow a random distribution.
b) Where the change in input is a fixed increment of any kind, neither the output nor the change in output nor any other order differential may be constant or cycle as a whole (though unpredictable repeats are a requirement of randomness), no matter what the period of that cycle would be.
These properties are common to almost all systems that are sensitive to initial conditions, which is why some of the more elaborate hashing schemes use well-understood chaotic systems rather than trying to mess around with the underlying cryptographic theory. If you know the system is deterministic (ie: for identical input it must produce identical output) but is non-predictable (ie: there exists no method whatsoever for figuring out the output - or even guessing the range it might fall in, other than the entire allowable range - for a given input except to perform the operation) then predicting a collision should be impossible. In practice, chaotic systems aren't the easiest of beasts to work with when you want fixed-length hashes and you want them yesterday. You could produce extremely strong cryptographic hashes chaotically if you don't mind waiting a day or two for each one.
In practice, no cryptographic hash will be totally "perfect", it can only be approximate. And the faster it needs to be, the more shortcuts you need to take, so the less perfect it can be even in theory. This is one reason there is some commentary on the SHA3 mailing list on whether speed should be as emphasized in the current test as the criteria suggest - that maybe NIST should relax that a little and get something stronger. Weaknesses in MD4, MD5 and even IPSec have been pointed out in respect to an overemphasis on speed in the past. Not sure on how far you could go with that, but the very impressive speedups achieved on the posted hashes suggests that the speed of the algorithm is a non-issue, that there are so many avenues for making the code faster that you can disregard that side of things almost entirely. At least for this contest. The better choice may well end up being the stronger choice, no matter what the relative performance of the reference implementations.
I could be wrong, but take a look at the following extract from the linked article:
"These patents--numbers 5,206,951, 5,421,012, and 5,226,161--referred to the integration of data between object managers, and between data managers, and to the integration of different programs that were manipulating data of different types."
To me, this sounds like an implementation of Java issue, not an issue with Java as a language. You could implement all kinds of mechanisms in the JVM that did the same thing but were not covered by those patents.
The implementation of a business method or algorithm is patentable, but the semantics fall short of a full implementation. Also, patents are not supposed to include those things which are "obvious". You could not patent the AND operator, for example, even if there was no prior art. (Ok, the USPO gets muddled on what is "obvious", which is why the one-click patent may or may not actually be valid.) For the most part, instructions in a language are "obvious" and also have oodles of prior art. It would be very hard to invent a computer language in which an instruction has syntax and semantics different from a conventional programming language in some non-trivial way and in which the instruction is still useful. Even then, interfaces are generally ruled unpatentable for the reason stated at the start - they're not an implementation, they merely describe in a highly abstract way what the end result of any member of the entire class of implementations would be. That's too vague. You can't patent ranges of inventions, only a specific invention.
In this case, the language is based on Haskell, so prior art immediately applies. A patent that attempts to cover a pre-existing method (obvious or not) should - if the judge is sober - be thrown out of court so fast it reaches escape velocity. Preferably along with any USPO clerk that allowed it. Since most crypto operations are likely to be simple boolean operands, power functions or modulo, and since these all exist in pretty well nearly all programming languages, anything not Haskell-specific is going to be prior art from somewhere else.
The result is that there is absolutely nothing in Cryptol that can be protected, save the specific implementation provided and there's so far bugger all evidence that their implementation is any more interesting than anyone else's.
You can't patent interfaces, only implementations. A language is not an implementation and therefore is inherently unpatentable. Well, except in the US, where apparently icons for data files can be patented. Ok, in theory languages cannot be patented. They don't define a process, they don't describe a mechanism, they merely codify the syntax and semantics of the building-blocks that can be used to build mechanisms or processes.
Far as I can see, it's a very trimmed-down formal language and not a whole lot more. Yes, a lot of the work is in the compiler, but there are plenty of well-developed compilers for languages just as well-designed, and a fair few are Open Source, not proprietary or with absurd conditions. And even those which are proprietary, such as Intel or Green Hills, the trial version is full-blown and not a toy edition. Re-implementing Cryptol as a front-end to an existing high-quality compiler, or as a translator (the cryptol-to-something equivalent of f2c) should not be overly difficult. Certainly not as hard as writing a Cryptol compiler from scratch of equal calibre.
As far as whether it would infringe on IP, I doubt it. Microsoft got walloped by Sun over using a trademarked name, not over the language per-se, which is why they could get away with just renaming it. But Microsoft couldn't take action against Mono or any of the Open Source.Net reimplementations because that's not something that can be protected. In this case, the worst that can happen is someone abseils down from a helicopter in the dead of night and sends you on a guided tour of Afghanistan. That's all. They can't sue you.
Since the number of problem-solvers is independent of the number of problems, and problem-solvers can examine multiple solutions to the same problem, along with a limited range of solutions for many problems, you can expect the number of publications to exceed the number of problems and the number of problem-solvers. However, you are correct that merely increasing the quantity of papers (which is all the current rules do) will cause the quality to suffer. The total thought put in to N papers over a period of time t cannot exceed the total amount of thought the brain can output over time t.
Sure, natural multitaskers will be able to better exploit the total amount of thought the brain can exploit when N exceeds 1, but if N exceeds their threshold, the quality suffers. For the rest of humanity, where single-tasking is the rule, N absolutely has to be 1.
Current funding rules for academia and research labs mean that quantity is profitable, quality is not. That is exactly the wrong way to get any real work done and is partly why papers on hyperdilution and test-tube cold fusion are serious money-spinners. They take no effort to write, get cited lots (even if by debunkers - doesn't matter, since funding is a function of the absolute number of citations and not by whether the citing papers agree), and grab the attention of potential external sponsors who couldn't tell a good paper from a confetti'd dingo's kidneys.
It's interesting, but predictable (in hindsight). Look at cable television. The US has thousands of channels, but most of them show extremely similar material, if not the same. The capacity to have choice should have, if the Long Tail was correct, engendered choice. In practice, it didn't. As Britain went from BBS's 1 and 2, and ITV, to five terrestrial channels and an ungodly number of satellite stations, the quality of broadcasts has dropped, not risen. The increase in the range of options has led to a reduction in the ability to choose something desirable.
Radio stations show another aspect to all of this. Most radio stations are now owned by a tiny handful of owners, like (Un)Clear Channel. Very few people bothered supporting their local station and very few people complain about the absolute uniformity in things like playlists today. The explosion of apparent choice has killed off the real choices.
I believe the Long Tail could be made to work profitably for on-line vendors, but not until this sort of apparent paradox is resolved. You have to start by making it harder to have stores mass-produced by a virtual xerox. There have to be incentives of some sort to encourage diversity and specialty, as that is when you can really maximize sales on obscure stuff - concentrate it in a few places rather than mush it over everyone.
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.
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.
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.
Peer-to-peer is being broken all the time. P2P poisoning is a common technique for killing shares in a specific file.
Authentication systems -ARE- falling over, Internet banking systems -ARE- highly exposed, the International Monetary Fund is said to have been cracked! It's too late to say "if if if", the "if" has been, gone, and stolen your cup-a-soup. It was already too late when the first rumours of a breakage in MD5 were surfacing. As JRRT point out in LotR, it's too late to call for help when the enemy army is on your doorstep.
The time to change is before things break, but when the probability of them doing so soon exceeds acceptable thresholds. Anyone who waits until things break before fixing them might want to talk to the ghosts of airline pilots on the wisdom of such a strategy. Anyone who waits until many years after the disaster has struck to consider jumping ship might want to consider the re-arranging the deckchairs on the Titanic as a future profession.
Hell, how long has it been since the DNS vulnerability was found? And how many home users have patched their cable modems or DSL modems accordingly? Of those, how many have, or are likely to in the forseeable future, been subject to attacks by zombies, phishers, or other malware/malbeings who can exploit such flaws?
Are they being smart? Hell no. Are they being wise, in not installing less-tested, less-proved, newer alternatives? Hell no. Are they being so conservative that stupidity is oozing out their ears like rampaging earwax? Oh most definitely yes. Are they worthy of so much pity that all software should be backwards compatible with their defects of software and defects of character? Oh God I hope not! (If ever there was a place for a God in this world, it would be to throw lightning bolts at people whose brains resemble a TRS-80.)
Slashdot Mirror
What we really need is a good recession somewhere around 2032-2033. That way, the idiots won't patch the time_t bug in time.
In a recession, managers will be even more eager to have nothing to be blameable over. Remember, underlings get sacked first. If they go with Microsoft, the managers will feel reasonably safe, even if it drives the companies under. They will be paid the longest and will be the most likely to be re-hired quickly. Going with Open Source will be seen as taking a risk, something that in risk-averse times will not be looked on favourably even if it DID save the company's bacon.
I see the recession as a time when views will become far more entrenched in existing companies. Start-ups may be willing to go with OSS, as they need to cut costs to a minimum and they don't have shareholders to placate, but expect extreme conservatism to reign supreme. At least for the first half of the recession. After that, some of the brain-dead companies will also be financially dead, and more dynamic companies may well be profiting from their early risks. But that's a year away at best. 2009 will not be a good year for OSS in business, though 2010 might well be.
A "perfect" cryptographic hash must meet three criteria:
a) The best herustic for determining an input which will produce the same hash as a specific target input will require as many steps on average as brute-forcing. (ie: the probability of getting a collision is the same whether you are using a programmatic solution or guessing.)
b) If inputs A, A' and A'' produce the same output, where A and A' are known, the best herustic for determining A'' will remain no better than one that brute-forces.
c) If inputs A and A' produce the same output as each other, inputs B and B' likewise produce the same output as each other, and so on for some statistically-significant number of distinct outputs, the outputs will follow a random distribution.
In other words, the apparent strength of the hash is the actual strength of the hash, no matter how much information has been obtained (either by analysis or by chance). There are two "obvious" properties which are necessary but not in themselves sufficient to produce those criteria. These properties are:
a) The change in output in relation to a given change in input will follow a random distribution.
b) Where the change in input is a fixed increment of any kind, neither the output nor the change in output nor any other order differential may be constant or cycle as a whole (though unpredictable repeats are a requirement of randomness), no matter what the period of that cycle would be.
These properties are common to almost all systems that are sensitive to initial conditions, which is why some of the more elaborate hashing schemes use well-understood chaotic systems rather than trying to mess around with the underlying cryptographic theory. If you know the system is deterministic (ie: for identical input it must produce identical output) but is non-predictable (ie: there exists no method whatsoever for figuring out the output - or even guessing the range it might fall in, other than the entire allowable range - for a given input except to perform the operation) then predicting a collision should be impossible. In practice, chaotic systems aren't the easiest of beasts to work with when you want fixed-length hashes and you want them yesterday. You could produce extremely strong cryptographic hashes chaotically if you don't mind waiting a day or two for each one.
In practice, no cryptographic hash will be totally "perfect", it can only be approximate. And the faster it needs to be, the more shortcuts you need to take, so the less perfect it can be even in theory. This is one reason there is some commentary on the SHA3 mailing list on whether speed should be as emphasized in the current test as the criteria suggest - that maybe NIST should relax that a little and get something stronger. Weaknesses in MD4, MD5 and even IPSec have been pointed out in respect to an overemphasis on speed in the past. Not sure on how far you could go with that, but the very impressive speedups achieved on the posted hashes suggests that the speed of the algorithm is a non-issue, that there are so many avenues for making the code faster that you can disregard that side of things almost entirely. At least for this contest. The better choice may well end up being the stronger choice, no matter what the relative performance of the reference implementations.
I could be wrong, but take a look at the following extract from the linked article:
"These patents--numbers 5,206,951, 5,421,012, and 5,226,161--referred to the integration of data between object managers, and between data managers, and to the integration of different programs that were manipulating data of different types."
To me, this sounds like an implementation of Java issue, not an issue with Java as a language. You could implement all kinds of mechanisms in the JVM that did the same thing but were not covered by those patents.
The implementation of a business method or algorithm is patentable, but the semantics fall short of a full implementation. Also, patents are not supposed to include those things which are "obvious". You could not patent the AND operator, for example, even if there was no prior art. (Ok, the USPO gets muddled on what is "obvious", which is why the one-click patent may or may not actually be valid.) For the most part, instructions in a language are "obvious" and also have oodles of prior art. It would be very hard to invent a computer language in which an instruction has syntax and semantics different from a conventional programming language in some non-trivial way and in which the instruction is still useful. Even then, interfaces are generally ruled unpatentable for the reason stated at the start - they're not an implementation, they merely describe in a highly abstract way what the end result of any member of the entire class of implementations would be. That's too vague. You can't patent ranges of inventions, only a specific invention.
In this case, the language is based on Haskell, so prior art immediately applies. A patent that attempts to cover a pre-existing method (obvious or not) should - if the judge is sober - be thrown out of court so fast it reaches escape velocity. Preferably along with any USPO clerk that allowed it. Since most crypto operations are likely to be simple boolean operands, power functions or modulo, and since these all exist in pretty well nearly all programming languages, anything not Haskell-specific is going to be prior art from somewhere else.
The result is that there is absolutely nothing in Cryptol that can be protected, save the specific implementation provided and there's so far bugger all evidence that their implementation is any more interesting than anyone else's.
You can't patent interfaces, only implementations. A language is not an implementation and therefore is inherently unpatentable. Well, except in the US, where apparently icons for data files can be patented. Ok, in theory languages cannot be patented. They don't define a process, they don't describe a mechanism, they merely codify the syntax and semantics of the building-blocks that can be used to build mechanisms or processes.
Far as I can see, it's a very trimmed-down formal language and not a whole lot more. Yes, a lot of the work is in the compiler, but there are plenty of well-developed compilers for languages just as well-designed, and a fair few are Open Source, not proprietary or with absurd conditions. And even those which are proprietary, such as Intel or Green Hills, the trial version is full-blown and not a toy edition. Re-implementing Cryptol as a front-end to an existing high-quality compiler, or as a translator (the cryptol-to-something equivalent of f2c) should not be overly difficult. Certainly not as hard as writing a Cryptol compiler from scratch of equal calibre.
As far as whether it would infringe on IP, I doubt it. Microsoft got walloped by Sun over using a trademarked name, not over the language per-se, which is why they could get away with just renaming it. But Microsoft couldn't take action against Mono or any of the Open Source .Net reimplementations because that's not something that can be protected. In this case, the worst that can happen is someone abseils down from a helicopter in the dead of night and sends you on a guided tour of Afghanistan. That's all. They can't sue you.
Kittehs hab been uzing cryptlol for yeers.
Since the number of problem-solvers is independent of the number of problems, and problem-solvers can examine multiple solutions to the same problem, along with a limited range of solutions for many problems, you can expect the number of publications to exceed the number of problems and the number of problem-solvers. However, you are correct that merely increasing the quantity of papers (which is all the current rules do) will cause the quality to suffer. The total thought put in to N papers over a period of time t cannot exceed the total amount of thought the brain can output over time t.
Sure, natural multitaskers will be able to better exploit the total amount of thought the brain can exploit when N exceeds 1, but if N exceeds their threshold, the quality suffers. For the rest of humanity, where single-tasking is the rule, N absolutely has to be 1.
Current funding rules for academia and research labs mean that quantity is profitable, quality is not. That is exactly the wrong way to get any real work done and is partly why papers on hyperdilution and test-tube cold fusion are serious money-spinners. They take no effort to write, get cited lots (even if by debunkers - doesn't matter, since funding is a function of the absolute number of citations and not by whether the citing papers agree), and grab the attention of potential external sponsors who couldn't tell a good paper from a confetti'd dingo's kidneys.
Yes, but the computer-generated reviewers can't get that software as a package for their distro.
It's interesting, but predictable (in hindsight). Look at cable television. The US has thousands of channels, but most of them show extremely similar material, if not the same. The capacity to have choice should have, if the Long Tail was correct, engendered choice. In practice, it didn't. As Britain went from BBS's 1 and 2, and ITV, to five terrestrial channels and an ungodly number of satellite stations, the quality of broadcasts has dropped, not risen. The increase in the range of options has led to a reduction in the ability to choose something desirable.
Radio stations show another aspect to all of this. Most radio stations are now owned by a tiny handful of owners, like (Un)Clear Channel. Very few people bothered supporting their local station and very few people complain about the absolute uniformity in things like playlists today. The explosion of apparent choice has killed off the real choices.
I believe the Long Tail could be made to work profitably for on-line vendors, but not until this sort of apparent paradox is resolved. You have to start by making it harder to have stores mass-produced by a virtual xerox. There have to be incentives of some sort to encourage diversity and specialty, as that is when you can really maximize sales on obscure stuff - concentrate it in a few places rather than mush it over everyone.
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.
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).
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.
(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.)
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?
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.
Peer-to-peer is being broken all the time. P2P poisoning is a common technique for killing shares in a specific file.
Authentication systems -ARE- falling over, Internet banking systems -ARE- highly exposed, the International Monetary Fund is said to have been cracked! It's too late to say "if if if", the "if" has been, gone, and stolen your cup-a-soup. It was already too late when the first rumours of a breakage in MD5 were surfacing. As JRRT point out in LotR, it's too late to call for help when the enemy army is on your doorstep.
The time to change is before things break, but when the probability of them doing so soon exceeds acceptable thresholds. Anyone who waits until things break before fixing them might want to talk to the ghosts of airline pilots on the wisdom of such a strategy. Anyone who waits until many years after the disaster has struck to consider jumping ship might want to consider the re-arranging the deckchairs on the Titanic as a future profession.
Hell, how long has it been since the DNS vulnerability was found? And how many home users have patched their cable modems or DSL modems accordingly? Of those, how many have, or are likely to in the forseeable future, been subject to attacks by zombies, phishers, or other malware/malbeings who can exploit such flaws?
Are they being smart? Hell no. Are they being wise, in not installing less-tested, less-proved, newer alternatives? Hell no. Are they being so conservative that stupidity is oozing out their ears like rampaging earwax? Oh most definitely yes. Are they worthy of so much pity that all software should be backwards compatible with their defects of software and defects of character? Oh God I hope not! (If ever there was a place for a God in this world, it would be to throw lightning bolts at people whose brains resemble a TRS-80.)