Nobody does. This is the first and most important rule of software engineering; most badly engineered projects I've seen got that way because people thought they knew more than they did, whether on the engineering, managerial or executive level.
Mark Twain said that what people don't know rarely gets them in trouble--what gets them in trouble is what they know that ain't so.
2. GOOD DESIGN CANNOT BE TAUGHT.
Good design is kind of like skydiving--it can't be taught. You don't really know beans about skydiving until you're headed toward the ground at terminal velocity, fumbling around for the D-ring (or lollipop, or throw chute, or what-have-you for your particular parasail). At that point, it all becomes crystal clear in the way that only being confronted with imminent mortality can make things.
Software design is much the same way. You don't know beans about software design until you're actually designing. See a project through from conception to fruition, and then take a look back on it. If your first experiences with real software design are anything like mine were, you'll be embarassed that your name is on it.
3. GOOD SOFTWARE IS GREAT, BUT BAD SOFTWARE TEACHES YOU MORE.
It's always nice to make software that doesn't suck, but you don't learn very much from doing it right. You learn from screwing up, then assessing your screw-ups and making different choices in the future.
4. THE BEST WAY TO LEARN SOFTWARE DESIGN...
... is by doing it. Find your itch and scratch it. Sit down with a notebook and sketch out how you think it should work, then sit down and code the monster. With luck, your design will suck. Print out your code, compare it against your design, and see where reality fell short of your goals.
Then re-code the monster. Make different choices this time; see how much more (or less) elegant your code appears.
Repeat this process ad infinitum until you get some code that you're moderately proud of. At that point, move on to a different project and start over again.
Before too long, you'll find your design skills improving by leaps and bounds. Remember: your goal here is not to make perfect software, but to learn about software. Don't be afraid to experiment, to fiddle around, to intentionally break your software just to see how it falls apart.
First off, there is no war. There is no conflict. Hell, there isn't even competition for mindshare, since all of the great KDE apps get GNOMEified in short order and the great GNOME apps get QTified in short order. It's possible that in the future this will cease to be the case as GNOME and KDE focus on not-entirely-compatible technologies (GNOME uses CORBA, while KDE is moving to a more lightweight toolkit), but for right now it's the case.
1. SPEED AND RESOURCE USAGE.
Benchmarks are lovely things; there are so many results you can choose to get.:) Find me a benchmark which says KDE is slow and I'll find you one that says GNOME is slow.
2. INTEGRATION BETWEEN APPS.
Oh, yes, we've seen in Windows 98 how integration between apps is always to the benefit of the end-user. (Note to KDE fans: I'm not comparing KDE's level of uniformity to Windows' sickening degree of the same. I'm just pointing out uniformity and integration are not the be-all of environments.)
There's a wise proverb about "a foolish consistency is the hobgoblin of little minds", or something to that effect. Consistency is good up until it becomes a foolish consistency, at which point it becomes horrible ("WTF does Microsoft mean, it's `intuitive' to view my hard drive as a freakin' webpage?!"). Does KDE have a more consistent look and feel? Yes, I'd agree that it does. Is this a selling point? Personal preference. To me, it's a nonissue.
3. APPLICATIONS AND DEVELOPER SUPPORT.
Both environments are breaking out all over with new applications and new developers. Last year I had to special-order Dallheimer's Using QT and Harlow's Developing Linux Applications with GTK+. This year there are far more books on the shelves relating to both environments. They're not on the bookshelves for their own sake--they're on the bookshelves because people have been asking for them, and because people are buying them. That shows more than anything else that both are alive and quite well.
4. KDE IS MORE FAMILIAR.
Only if you've got a lot of experience using KDE or Windows. Remember: a foolish consistency is the hobgoblin... If GNOME thinks they have a better GUI, then they should put that forward. If the GNUStep people think the OpenStep interface is the be-all end-all of GUIs, they should put that forward.
Horse-and-buggy transportation was much more familiar to people at the turn of the century. Should I take it they were all fools to abandon the system they knew to experiment with the newfangled, crochety, prone-to-breakdown Model T?
5. HONORABLE MENTION IN THE FUD CATEGORY
"[The GNOME developers] seem to think that putting the biggest, most memory hogging features into the DE will automatically make it better..."
If you didn't bother to read the press release, GNOME 1.2 takes up fewer system resources.
"Software size and quality seems to not be a very top priority, and software speed seems to be an even lower priority..."
Strange. Most of the GNOME apps I've seen are pretty modest in their memory footprint. Insofar as quality goes, I've never had any complaint.
"Features seems to head the list, and everyone knows what that mentality gets you... it gets you Windows 2000."
GNOME is not about features. Making that assertion shows that you really don't grok the free software movement at all.
GNOME is about choice. Don't want to use Gnome Terminal? Great, use Powershell. Don't want to use Powershell? Fine, use an xterm.
First, I am not attempting to come down on either side in the "you can't do OO in C" war. Fact is I think you can, but for a lot of reasons I prefer C++ for OO.
Functionally, OO in C requires you to construct each object manually. This, by itself, is a major pain in the hind end. You wind up having to write code to initialize each new object (big deal--you have to write it in C++, too), and you have to remember to call each initializer.
Destruction is identical but in reverse. Unless your object is pretty trivial, you've got to remember to free those valuable system resources.
It's also difficult to do data hiding in C. In C++, you can declare things to be safely inside the black box, away from the grungy hands of the hackers who don't understand your code and whom you don't want futzing around with your code (and sometimes that grungy hacker is you, six months later, doing something hare-brained and stupid because you've forgotten some small detail). In C++, we've got lovely words like "private" and "protected" to help keep us from shooting ourselves in the foot.
There's foo, bar, baz and quux as well as construction, destruction and data hiding. The fact of the matter is that OO in C is definitely possible, and does not need to be an ugly hatchet job. You can have beautiful, elegant OO code in C.
Remember that the first C++ "compilers" were really preprocessors (anyone remembet AT&T's cfront?), which took a C++ source file and mangled it down into OO C.
OO in C is gruelingly difficult; I always forget to explicitly call my destructor functions, for instance. C++ has better support in the language for OO code, which is why I'm a C++ hacker more than I am a C hacker nowadays.:)
It would appear your paranoia is aimed far too specifically: paranoia at our profession being shaken up, perhaps fundamentally.
I like fundamental shakeups. I consider the invention of quantum cryptography to be a far more interesting shakeup than quantum computation. Even quantum cryptanalysis is more interesting than quantum computation.
Theoretically, quantum algorithms can test all of the potential factorizations for a key of arbitrary length at once.
You confuse `theory' with `practice'. In theory, a massively parallel Turing machine can compute all of the potential factorizations at once. In practice, we don't worry about this--why? Because it's not going to happen, and we've got a lot of mathematics and physics to back us up.
How many electron energy states are there? That number is on some level fundamentally connected to how much computation can be done--every state corresponds to a different aspect of the number-crunching. There are a finite number of energy states; there is a finite amount of computation a quantum computer can do.
At a conference recently when a paper was presented detailing the latest results of quantum computing, Schneier was heard to mutter "well, gee, any RSA modulus less than three bits is in real trouble..." Will quantum computers get better? Yes--up until about 15 qubits in length. At that point, our current models break down and we're going to have to invent entirely new technology.
Currently, we have absolutely no clue--not even well-thought-out theoretical models--of how to proceed from the 15-qubit level.
All of our algorithms which rely on the difficulty of factoring arbitary prime numbers will suddenly be completley useless and obsolete.
Yadda yadda yadda. I've heard "The Death of Public-Key" for twenty-five years, thank you--yours is nothing new. To factor a 3,072-bit RSA modulus, you'd need something on the order of a 1,536-qubit computer.
That's right. 1,536 qubits.
Even assuming that quantum computation follows a modified Moore's Law and our qubits double every 18-24 months, we're still looking at 15-20 years.
Let me repeat: I am not worried.
Of course, quantum coupling provides a possible solution in the form of an unbreakable one-time pad, but how this can be applied to problem sets which public key/private key encryption addresses remains to be seen.
Quantum computation does not provide any kind of unbreakable Vernam cipher. Quantum cryptography permits secure negotiation of symmetric keys over insecure lines of communication, but that's in no way related to the Vernam cipher. What the heck are you talking about here?
If and when quantum computing does become feasable, security as we know it will be turned on its head, and keylengths of whatever length will be compromized, regardless of your level of paranoia. The entire paradigm will be obsolete, and the entire security infrastructure will have to be rethought from the ground up.
Quantum computing is already feasible. The first electronic computers were used to break fairly sophisticated mechanical ciphers, and they had far less computing horsepower than your alarm clock today. When a wildly divisive technology is introduced, its repercussions are seen and felt almost immediately--look at how much digital computers have overturned our world in the last fifty years.
Quantum computers are not an "if and when" proposition. They are feasible, right now, albeit in a very limited state. So is Leonard Adleman's biological computing paradigm. Both of those have the potential to be incredibly disruptive to whatever fields of CS haven't thought of its ramifications.
keylengths of whatever length will be compromized
Oh, give me a break. Look this stuff up--it reduces the keyspace by an exponential factor of.5. It does not magically compromise everything. Breaking a 256-bit cipher with quantum computation is as hard as breaking a 128-bit cipher with a Turing machine.
I am an InfoSec professional in real life, but I am not speaking in my professional capacity here.
If quantum computers ever come to the forfront, security as we know it today will be a thing of the past..
Poppycock. The theoretical ramifications of quantum computers have been well-known for many years now, and there's been a lot of good academic research on exactly what quantum computers are capable of. They will be neat toys when they arrive, but they will not mean the end of security as we know it.
Put bluntly, using quantum computers you can manage to cut the keyspace by an exponential factor of.5--that is to say, a keyspace of 1,000,000 elements gets pulled down to 1,000 elements. This sounds like a lot, and it is; being able to take the root of the keyspace is a big achievement for some sorts of computation.
Crypto is not necessarily one of them. One of my current clients is concerned about quantum computers being invented and fielded in the next twenty years. So what we're doing is figuring out what sort of keyspace could be reasonably searched in 20 years (assuming a steady progression of Moore's Law), then moving one step past that... and then squaring it.
To give you an idea, 256-bit ciphers will be immune to brute force attack for as long as we're living in the Solar System. Do the power analysis on it; to break a 256-bit cipher by brute force using quantum computers requires an amount of power which borders on the absurd.
Now, that being said, any kind of serious projection about "how much key is enough" is preposterous, especially once you get past five years in the future. That only underscores the ludicrousness of your "security as we know it will be a thing of the past" statement. Security professionals already assume that the opposition has access to ten billion quantum Turing machines. We're paranoid. We're professional paranoids.
Am I concerned for what quantum tech will do to crypto? Yes. Am I shaking in my boots over it? Not hardly.
Yep, that's right--it's not a hard science like mathematics or physics except in the most facile and shallow way. Every engineer should have a background in human factors as well as scientific ones. Our creations are ultimately used by human beings, and we cannot afford to neglect them.
2. ENGINEERING IS AN ART FORM.
Engineering is not simply "creating stuff that works". While possible, it hardly contributes to the human race as much as aesthetic qualities like grace and elegance do. Compare an I.M. Pei or Frank Lloyd Wright building with a Soviet-era fish cannery--which one do you think adds more to the world's culture, designwise?
3. SOFTWARE ENGINEERING IS A HIDEOUSLY BROKEN FIELD.
The axiom is that "if carpenters built homes like we build software, the first woodpecker would destroy civilization". No other form of engineering permits the kind of widespread failures and bass-ackwardness which we do. Most Professional Engineers I know (the people who get to add "P.E." after their name) can't stand the thought of programming being elevated to the level of an engineering discipline, because they see us--correctly, for the most part--as Johnny-come-latelies who are concerned only with making a buck and looking cool, not building things which will stand the test of time.
4. MY GOALS
My goals are formed by these principles. Number one, my ultimate and overarching ambition is to make software which is helpful to society and individuals. Second only to that, my goal is to make elegance an integral part of my work. Third, I aim to write software which doesn't suck.
As long as my job permits me to do all those three things, I'm happy. If I write a piece of software which manages to achieve all those things, I'm happy. Right now I'm polishing up Fishtank-1.0.1 for release (a GPLed, elegant, well-documented crypto library; email me if you want to see a pre-release) and I think it's been guided by those principles. I'm happy with it, and that leads to my final, most important, goal:
RMS is unquestionably brilliant, but he is not always right; and while I have the utmost respect for his free software ideals, I have extreme difficulty with the zealotry which some of his supporters demonstrate.
Your first assumption is that Linux developers are not Linux users. You assume that a commercial software company's programmers aren't going to give half a damn about the operating system; you assume they're heartless, faceless, interchangeable capitalists.
News flash for you: every one of those assumptions is faulty.
The people who code under Linux, whether it be for pay or for the good of the community, are going to be familiar with Linux and the community spirit which it was built upon. When you demonize the commercial software developers, guess what? You're demonizing people you should be evangelizing to. Your approach is no different from that of any of thousands of fundamentalist Christians who loudly scream that homosexuality is evil--regardless of whether it is or not, it alienates the very people you're trying to reach.
Your second assumption is that it is an us against them situation. How can I put it bluntly?--I consider this to be a sign of immaturity. RMS may well see the intellectual-property issue in black and white, but he does not see people in terms of black and white. He has more wisdom than that.
Your third assumption is that our rules are better, high in fiber, low in saturated fat, and guaranteed low sodium. While I'll be the first to trumpet the virtues of free software, we will not achieve world domination by means of xenophobia. Without exception, every culture in history which has practiced isolationism has had its butt kicked by the cultures which did not. Do you really want the free software community to get our rear end handed to us on a platter? That's what this kind of isolationism and xenophobia will do, make no doubt about it.
If I were a Windows developer who was considering porting something (like, for instance, let's say a science-fiction MMORPG to Linux) I'd take a look at your post and say "good grief! What a strange person. Well, Marketing says there's a contingent of them who will buy games anyway, so I'll just ignore all of these Linux zealots!"
As soon as that happens, you have forever lost them to the cause.
Commercial software will not be the demise of Linux. Linux is bigger than that, and more importantly, the community is stronger than that. The only thing that can kill Linux--and destroy free software--is the community surrounding it.
And you're doing ten times as much to destroy free software as any closed-source programmer is.
A bunch of idiots with guns are not going to be able to overthrow the army of the greatest super power in the world. Even if there are a million idiots. The idiots dont stand a chance against tanks, machine guns, planes, and other high-tech high-damage weapons of the military. So this reason seems absurd.
The Romans at Cannae...
... The British at Isandhlwana...
... The French in Indochina...
... The Americans in Vietnam...
... The Russians in Afghanistan...
... and again in Chechnya...
I'll wait while you go look up the history required to realize that guerilla movements originating from an armed citizenry have this annoying habit of wrecking even the best-trained and equipped armies.:)
I'll try as best as I can to answer your questions. Again, remember: IANAL.
Registration of firearms in no way infringes anyone's ownership of a firearm as long as anyone could register a firearm.
The problem is that no other right enumerated in the Constitution requires registration in order for its exercise. The courts have ruled that it is forbidden to require registration to run a newspaper; it's forbidden to require registration to run a church; it's forbidden to require registration to keep the Army from quartering soldiers in your home.
To phrase things in Net terms, registration is an "opt-out" system. It's the Government saying "we're going to deny you this right, unless you specifically inform us that you intend to exercise it".
The Federal courts have historically been extremely harsh when the government has tried these things. If the courts let the government require registration for the exercise of the Second Amendment, then there is no lawful reason to prevent the government from requiring registration for the exercise of the First Amendment.
There are laws on the books requiring permits for large assemblies of crowds. These laws have been upheld only so long as they impose no significant inconvenience and they exercise no prior restraint. That is to say, the permits have to be issued extremely quickly, and the government is not permitted to deny permits to any organization. This is not the case with firearms registration. When I purchased my.45, I had to present the county sheriff with a copy of my lease agreement (to prove I was a resident of the State and county from which the permit would be issued), my driver's license and passport, I had to be fingerprinted, I had to wait a month, and I was interrogated for half an hour by the Sheriff (he said he just wanted to make sure I could handle difficult social situations without losing my cool). After going through all that, my permit was issued to me--but at any time the Sheriff likes, he can revoke my permit to purchase.
That counts in my book as a significant inconvenience and an unlawful Government control over a Constitutionally-protected activity. It isn't at all in the same ballpark as permits for large assemblies.
There was a case recently in which the Court decided that the right to assembly didn't include the right to anonymously assemble (thus requiring large Klan gatherings to be hoodless), and I'm still trying to decide how I feel about that.
So what is meant by a well-regulated militia? It may refer to groups organized by states or communities and drilled for the common defense of the people.
If you'd read my previous post, you'd have noticed the references to "select and elite corps".:) I already answered your question in part. To summarize, it is extremely clear that the Second Amendment is not meant to preserve the right of the nation to create an FBI or Army, the States to create State Troopers and National Guard, or communities to create police forces.
Exactly what the "well-regulated militia" means is still being hammered out in court. Check out Emerson v US, coming out of Texas.
Also, the Supreme Court has frequently curtailed "rights" given by the Constitution to "the people". Free speech, rights to a jury trial, rights of a defendant to confront their accusers, unfair seizures, etc.
Not in recent years. Lopez v US put significant restraints on Congress' power to pass law, for instance. Free speech has consistently been upheld by the Supreme Court; the right to a jury trial has never been abrogated, to the best of my knowledge; the right to cross-examine has been sacrosanct. The seizure provisions of the IRS and drug code may be morally repugnant, but I am unable to provide Supreme Court citations which affirm their Constitutionality. I strongly suspect that if they ever go to the Supreme Court, that the Supreme Court will strongly and viciously cut them down on Constitutional grounds. If I were the United States Solicitor General, I'd live in quaking fear of the grilling I'd get from Scalia or Thomas on those issues.:)
If you're going to rake the Court over the coals for being asleep at the switch, then you're going to have to provide me citations. On the whole they do extremely good work; the problem is that Congress churns out laws by the thousands and the Court can only give in-depth review to a few dozen cases per year.
If you want more bios on Federal judges, by all means--go on and read their bios. Almost all of them have bios available on the Web. You'll find that a great many of them are former beat cops; FBI agents; soldiers (oftentimes from Special Warfare branches, like the Rangers and SEALs). Until you actually go and check out their bios, please don't tell me they're unqualified.
I make no claim on whether or not short-barreled shotguns have a purpose in home defense or in military use. Short-barreled shotguns have been used in military service as far back as the Civil War; even farther back, all the way to Major Robert Rogers, if you're willing to accept shotgun-style weapons (blunderbuss, etc.).
However, the defendant in Miller did not introduce those historical facts into the court record. It's very possible that, had Miller been wise enough to introduce those terms, the Court would have decided other than they did.
The Court only determines cases based on the facts presented to them. The burden is not on the judge to be an expert in every respect of every discipline of study; the burden of the judge is to be able to learn quickly, very quickly, and to let all parties at trial educate him/her in the discipline in question.
Look at Judge Thomas Penfield Jackson, who had no technical experience before the DOJ/MS trial, and how technically astute his Findings of Fact were. Although there were some shortcomings, on the whole he grasped the subject matter very well. This surprised the court commentators to no end, but it came as no surprise to me--I've seen firsthand just how rapaciously judges learn new things.
I'm done debating this subject now; I don't think you're bringing up any new or interesting points here.
In a nation governed by laws, who else is going to determine how the laws apply besides judges?
I also dispute your underlying assertion; namely, that judges have no background in firearms and/or military conduct. I know of one Federal judge, one small step below the Supreme Court, who served as an Army Ranger in the European Theater in World War Two and participated in the D-Day invasion. Another judge I know is a retired Navy SEAL from the Vietnam era.
Personally, I think either of those two would have almost ideal qualifications to judge which weapons are deserving of Second Amendment protections and which are not.
(Went white-water rafting with the SEAL in '91. You could tell he was a SEAL... he jumped out of the boat just before the waterfall, just for kicks.)
No, I'm not going to tell you who they are. They both operate in the 8th Circuit. If you're really interested, you can check the bios of all the Federal judges in the 8th Circuit and find out exactly which two I'm referring to.
Under Iowa law (interesting fact--yes, I am a citizen of Iowa and yes, this law is still on the books), as an armed citizen of fit body and legal voting age, I am a member of the armed citizen militia.
The last time I had to use a gun to preserve the security of my free state was August, 1998. Someone was being beaten to death by a teenager with a tire iron. I called 911 and grabbed a shotgun. The perp decided that my 12-gauge beat his tire iron both in damage and in range, and he made the intelligent, rational decision.
No shots were fired, and for that I will always be deeply thankful. Most frightening experience of my life, let me tell you. Afterwards I had the shakes and vomited myself into the dry heaves.
IANAL, but I do follow the Bill of Rights pretty closely and have performed a fair bit of scholarship on the issue. In the spirit of disclosure, let me say that I possess three firearms and I enjoy participating in the shooting sports.
The overall intent of the Second Amendment is clear: that the citizenry is meant to possess the right to bear arms for the defense of themselves and of the community. This view is fairly universally shared by everyone in the gun control debate, save for those few who claim it only protects sporting purposes. (I cannot grant any credibility to these claims; in all my scholarship on the Bill of Rights, I have never found any hint from any of the Founding Fathers which suggests that any portion of the Bill of Rights is meant to ensure continued sporting activity.)
The real interesting portion comes in how you interpret that original intent. The more militant members of the pro-Second Amendment community (such as the poster I'm originally responding to) claim that all gun control is illegal; the more militant members of the anti-Second Amendment community (such as Sarah Brady) maintain that guns are inherently regulable.
Neither opinion is, in the opinion of the Supreme Court of the United States, worth a bucket of steaming excrement.
The pro-2A crowd fails to notice US v Miller (I think that's the proper cite), where a man convicted of possessing a sawed-off shotgun appealed to the Supreme Court on grounds that it unlawfully violated his rights. The Supreme Court said that it was unable to see how the possession of a sawed-off weapon contributed to the "well-regulated militia" and therefore received no Second Amendment protection.
Sarah Brady and HCI take US v Miller as proof that all weapons are subject to regulation. This is incorrect; a reading of US v Miller indicates that only those weapons which serve no useful purpose to a well-regulated militia can be arbitrarily regulated. In a strict interpretation of the Court's decision, Miller is actually a vindication of the Second Amendment in that the Court comes very close to outright stating that weapons with military applications (such as fully automatic assault rifles, etc.) possess Second Amendment protection.
So. According to Miller, weapons are regulable if they possess no utility to a militia. It's not as clear a victory for the anti-2A crowd as they make it out to be, and it's not a defeat for the pro-2A crowd, either.
That's the most recent Supreme Court cite which addresses the original poster's "all gun control laws are unconstitutional" argument. Now to take the flip side:
The anti-2A crowd likes to forward the idea that the Second Amendment is a collective right; that is to say, that the use of "the people" refers to the State or Nation as a collective whole and not the people individually. This fails both legal and historical tests.
Legally, to interpret the Second Amendment's use of "the people" in a collective sense would force the Supreme Court to interpret every other instance of "the people" in the Constitution similarly. The Court has refused to do this on multiple occasions, and as recently as a few years ago has referred in passing to the Second Amendment as a right which belongs to individuals.
On the historical side, George Mason (I believe) famously stated "Who, then, is the militia? Now it is the whole of the people." That by itself is a fairly clear statement from the Founding Fathers; considering that no-one at the convention spoke after Mason to condemn that assertion, we may assume it enjoyed widespread popularity.
Moreover, national and state militias composed of citizen-soldiers were known to the Founding Fathers. They were referred to as either "elite corps" or "select corps", depending on which authority they were chartered under (ref: Tennessee Law Review. If the intent was to guarantee the national and state rights to assemble armies and National Guard units, the Amendment would have read "Well-regulated select and elite corps being necessary to the security of a free state..."
So the anti-2A argument that the Second Amendment only protects the Army and National Guard units is obviously, blatantly incorrect.
There is still a great deal of litigation going on in an attempt to clarify exactly what the Second Amendment means. For recent Court decisions, I'd suggest you look at Lopez v US, in which the Court found that Congress had overstepped its Constitutional authority by restricting the possession of firearms near schools. This wasn't a Second Amendment case, per se, but it was a clear indication from the Court that it thought Congress had significantly overstepped its mandate.
Also, check out Emerson v US, coming out of Texas, where the Lautenberg Amendment (which strips people of their Second Amendment rights if they have any misdemeanor domestic-abuse conviction or restraining order filed against them) was overturned. In Emerson, a Federal judge found that misdemeanor convictions and restraining orders were insufficient process of law to strip someone of rights guaranteed by the Constitution.
Recently, the murder rate in DC has fallen considerably (or so the statistics say--but then again, considering how easy it is to lie with them...). Still, Washington DC has a reputation for being an incredibly unsafe city in which to live, as well as a city which is incredibly inhospitable to the Second Amendment.
The comment which was made was done in the spirit of sarcasm. A great many people, including the vehemently pro-gun control Mike Royko, have observed that the cities in the U.S. which have the most gun control also have the most crime.
The NRA would like you to believe that gun control leads to crime. Their logic is that with a disarmed citizenry, criminals can commit their depradations without fear of armed reprisal from their victims.
Other organizations, such as Handgun Control, Inc., offer the view that strict gun control laws are passed as a reaction to the lawlessness which widespread gun ownership brings.
I tend to side more with the NRA than with HCI on this issue.
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
Schneier has a long and very distinguished history of breaking protocols. He discovered attacks against IPSec and Microsoft VPN; I believe I saw his name on a couple of papers breaking various cellular phone protocols.
If you scoff when you hear Schneier called a "security expert", then you don't understand what his credentials are. Is he God? No. In fact, Schneier's been flat-out wrong before (anybody here remember MacGuffin, and his latest campaign against elliptical curve cryptography?).
But to say that Schneier is a crypto expert and not a protocol expert flies in the face of Schneier's body of published work.
Standard disclaimers apply, as always. (I hate living in a lawsuit-happy culture.)
What also might be good is to include protocols which, while working today, are not scalable to future systems. Right now I'm employed by a company working in the electronic publishing market, and it's surprising how many otherwise-good ideas are completely impracticable. (The good news is, the worst offenders are all proprietary. The open systems have fared the best.)
Last year during CRYPTO99, some IBM researchers released a paper which was lauded as having provable security. Caused a minor media uproar, up until it was broken. Turns out that if you can create an environment where just one of the assumptions behind the protocol is no longer valid, the entire protocol fell apart. I can't think of the name of it for the life of me, though. It didn't exactly impress me as being the Holy Grail, and I wasn't exactly surprised when it was broken.
Another good example is Microsoft's Virtual Private Networking. Version 1.0 was horribly broken; version 2.0 was a considerable improvement, but since it was (is) downwardly-compatible with 1.0, it's also bug-compatible with 1.0.
Then there's Netscape's SSL difficulties from version 3 (?). Although the SSL protocol was implemented correctly, Netscape's random number generator was deterministic.
Then there was the telco which was using the standard C rand() function to create random session keys (company name withheld, but yes, it's a big one).
A major credit-card company (you probably have one of their cards in your wallet) depends on nobody being able to break repeated-XOR encryption and having enough knowledge of IBM's SNA in order to eavesdrop on their network.
... I don't know as much about academic protocols being broken through the standard literature as I do about brain-damaged implementations of protocols. I'm a practical cryptographer, not a theoretical one. But good God, if you were to make a top ten list of the stupidest protocols (and implementations thereof), you'd spend years just trying to whittle the list of thousands of candidates down to the ten worst.
I don't know. I'd have to think about it for a while to come up with my own list of candidates for the Provably Stupid award. Ask me again tomorrow and I might have a better idea.:)
I am an InfoSec consultant in real life, but I am not speaking in any professional capacity here.
First, I've got to say that I'm glad that someone has come out with a companion to Applied Cryptography; where Applied Cryptography talks about ciphers in some detail, it's woefully light on protocols--and most of the interesting security attacks out there are protocol attacks, not cipher attacks. If the review posted is accurate, then we can use it as an adjunct to Menezes and Schneier, not as a replacement. This is a Good Thing(tm).
Second, for all that I'm looking forward to buying this book, I think that it ignores a very rich and informative part of the subject. Why not take a book of the same size and cover failed protocols, and explain where the protocols failed and why? I like to joke that there are only three or four different protocol attacks; software authors just insist on renaming them for every new system. An awful lot of good could be done by educating software engineers about what has failed, in the hopes that people will learn and not make those same mistakes again.
I'm grateful to Bruce Schneier and Alfred Menezes for their introductory works in crypto (and compared to graduate-level mathematics, Schneier's and Menezes' books are introductory), but I sometimes fear that they lull software engineers into a false sense of security; people think that "well, since Schneier says 3DES is secure, I can just use that and be safe". It's very tempting to do that, but security is not something which can be added into a piece of software like you can add salt to a recipe. It is a mistake to take a cookbook approach to security, which is the unintended consequence of books such as these.
What I'd really love to see is a book which shows failed protocols, and the dangers of cookbook security.
Having a cookbook available doesn't guarantee that what you cook will be edible.
Hashes are built on encryption operations
on
QNX Crypt Cracked
·
· Score: 2
I am a professional InfoSec consultant, but I am not speaking professionally here. This is not my professional advice.
Don't encrypt passwords, hash them!
Hash algorithms are intimately related to encryption algorithms; so much so, in fact, that you can take any iterative block cipher and turn it into a hash. Just run it in CBC mode with a fixed key and IV, and your last ciphertext block becomes a hash of the algorithm. The hashes which are produced with most block ciphers are weak, but that's because most block ciphers today use 64-bit blocks--64-bit hashes simply aren't big enough. Using an algorithm like Twofish or Rijndael (both AES candidates, which have 128-bit block sizes) allows you to create a modestly good hash algorithm.
That said, dedicated hash algorithms are likely going to be stronger than strong crypto converted into a hash algorithm. It's just as much of a fickle art to craft a good hash algorithm as it is to craft a good encryption algorithm. Ron Rivest is (rightly) hailed as a brilliant cryptographer, but he's still yet to make a uniformly strong hash algorithm. (MD5, while still in wide use, has some vulnerabilities; while it's secure enough for most purposes, it is not -uniformly- strong. Even the NSA has problems, as demonstrated by how quickly SHA-0 was abandoned for SHA-1.)
An interesting login scheme that I've heard of is ridiculously simple. Have a user send a timestamp to the server, signed with their asymmetric public key. The server attempts to check out the signature; if it passes, great, the user is authenticated. It's not perfect by any stretch of the imagination--it's vulnerable to all the attacks presently existing against asymmetric cryptography, and probably has another vulnerability or two in there somewhere--but it's an interesting and simple solution to the problem.
Due to a bug in Slash, the message directly above this in the thread (BAYWATCH.JPG) was attached as a response to the wrong message. A newbie was asking a question about multiple encryptions in weird and unexpected ways, and whether or not it could provide security. So please--hold the flames, I really *did* respond to the right message, honest.:)
1. Try and display it as a.JPG. Wow, guess what, it's not a.JPG... must be something else.
2. Look at the first few hundred bytes of the file. Almost every distinctive filetype out there today has distinctive header information. Standard compression libraries (PKZip, zlib, etc.) have very well-known headers.
3. Try to unzip the BAYWATCH.JPG file. Hey, it's asking for a password. Damn.
4. Leaf through my notebooks to find PKZip's encryption algorithm (it's trivially weak, but I don't remember its implementation off the top of my head).
5. Ah ha! I've found the cipher that's used in PKZip. Now I've just got to write a Perl script that'll break the cipher--it is a trivially weak cipher, after all.
6. Presto. Now I've got the original file back, or so I think. I take a look at it with a hex editor. Hey, this is... another ZIP file! Well, damn. Smack it around with the Perl script once more.
7. Check the file again. I've suddenly got the secret recipe for the $250 Neiman-Marcus cookies. I hand over the fruits of my labor to Boris and Natasha in the hopes that they will use these cookies to lure the moose and squirrel to their doom.
... Looking through the chain, you've got some file (FOO.BAR) which you compressed using PKZip (FOO.ZIP). You ran it through uuencode and uudecode (net result, no change), leaving it as FOO.ZIP. Then you just compressed-it-with-password again and renamed it BAYWATCH.JPG.
Total time for me to break it--six hours. That includes time to write the Perl script to break PKZip's encryption (provided I don't already have one somewhere), time to debug the Perl script, and enough time to order a pizza and have a decent lunch while I work.
If I've already got a Perl script to rip PKZip's encryption, then figure it'd take me about fifteen minutes.
What I want to say is: if you are smart enough to leave no traces (or better yet, lure the crackers to a wrong trail), could even a 'mediocre' encryption algorithm (or combos thereof) be 'secure enough'?
... I hope this post answers your question. The short answer is "no". The long answer is "usually, no".
Although I am a professional InfoSec consultant in real life, my opinions expressed here are not to be interpreted as my professional opinion. (There. Now that the legal disclaimers are done...)
1. ECC is not patent free. Several companies are engaged in patent war over ECC (Certicom being the number one). The "nice" curves have already been patented (mathematicians in the audience will crucify me for describing some curves as "nice", but it's a reasonably accurate layman description--some curves make crypto easier than others, hence they're "nice").
2. ECC is not faster than RSA. RSA is not faster than ECC. Nor are they equal in speed. While this all sounds terribly contradictory, it's all true; as we all know from having complained about NT-versus-Linux benchmarks, whoever is paying the analysis firm gets the results they want. When Certicom pays for ECC-versus-RSA, it always turns out that ECC is faster. When RSADSI pays for it, it always turns out that RSA is faster.
Even assuming that ECC were unambiguously faster than RSA, it wouldn't make a tinker's dam of difference. The applications which use asymmetric cryptography extensively are few and very far between. Symmetric ciphers have a better foundation in number theory, are more thoroughly cryptanalyzed and are often faster. Most of the time when asymmetric crypto is used, it's only used to negotiate a symmetric key. If it takes RSA a millisecond to encrypt/decrypt a 256-bit Twofish key, what do I care if it takes ECC a microsecond to do the same task?
3. RSA smartcards have existed for years. Check out the iButton for an example of how asymmetric cryptography can be used in smartwear (jewelry, buttons, etc).
Insofar as Schneier's distaste for cracking contests, I've got to say I'm in the same boat. Running a cracking contest doesn't prove anything. It doesn't prove it's secure, brute-force cracking rarely betrays insecurities, and what it's best at is media hype. PHBs the world over look at cracking contests and say "Wow, ECC stood up really well to that distributed attack, I guess it's safe for us to use!", without even once bothering to learn what the theory behind ECC is.
Schneier himself uses contests, so it's disingenuous to suggest he claims contests have no value. Schneier's Blowfish contest offered a cash award to the best cryptanalytic results against Blowfish, regardless of whether or not those results led to a break. That seems to me to be a more healthy way to run contests, although I'm still not entirely sold on the idea.
First, I am a professional information security consultant. Second, no, this is not professional advice; do not rely on it without first verifying.
However, unlike DES, there is no known mathematical loophole
Wrong answer, thank you for playing. DES is one of the most, if not the, most thoroughly-analyzed ciphers of all time. So far, the best way to break DES is by a brute force attack. There are some attacks against it which some people use as proof that the NSA put a backdoor in it, but these attacks are extremely esoteric -- for instance, the key complementation property means you only have to test half the possible keys; this reduces the difficulty of some attacks (chosen-plaintext attacks, specifically, although I think Eli Biham has a known-plaintext version) by a factor of 2--meaning the keyspace is only of size 2**55, not 2**56.
The rules for using DES are simple. Don't use weak keys; don't use complementary keys; use it in DESede (aka TripleDES) mode. The resulting ciphersystem is as close to unbreakable as you're likely to ever get. If your system is eventually broken, you can be reasonably certain that the cipher was not the subsystem which suffered the breach.
I trust DESede more than I trust Blowfish, more than I trust IDEA, more than any other symmetric ciphersystem out there.
Interestingly enough, so does Schneier. A few months back at a crypto conference someone in the gallery asked him what the strongest cipher today was. As I recall, his words were "Triple DES. There is no question."
Weeeeellll... since VA and Andover are both publicly held, their administration can't do anything that doesn't benefit the stockholders financially. If they *do* do that, they'll get their pants sued off, and lose their jobs.
Not true. Corporations do things which are adverse to profit all the time. Sometimes it's more accurately a case of putting off short-term profits for a long-term gain, or sacrificing long-term profits for a short-term gain. Or sometimes it's just because they think it's the right thing to do -- kind of like how some European automakers do not enforce patents on safety mechanisms, because they feel that safety is more important than profit.
Microsoft has long been a significant contributor to the Free Software Foundation. I don't know about you, but I'd consider that adverse to Microsoft's self-interest. (The donations come through the United Way campaign. Microsoft has a pledge to match employee donations to United Way charities, and the FSF is a UW-approved charity.)
Id Software has GPLed Quake; Bungie Software has GPLed Marathon 2: Durandal. While these software products are getting long in the tooth there was still a market for them. These two prestigious gaming companies intentionally forfeited profit, because... well, you'll have to ask Id and Bungie.
Corporations do things adverse to their own financial interest all the time. Claiming otherwise shows a lack of historical knowledge.
I don't have any personal opinion on the merger, except that VA now owns both sourceforge and server51, so the only non-VA free development platform-type-site that I know of is openprojects.net. But that's a different point altogether.
RHAD doesn't count as a free software development site? What about all the websites devoted to kernel hacking? Whatever happened to email?
The Linux community survived just fine before Sourceforge or Server 51. I've made significant contributions to free software projects and I've never even visited either of those two sites.
If Sourceforge and Server 51 were essential to the development of free software, then yes, I'd be irked about one company owning both. But they're not essential, so why worry?
Oh, and themes.org and Slashdot are now owned by the same people...isn't that exciting? But, of course, the Andover/VA Linux staff has no say in what gets posted and what doesn't.
The first rule of journalism is don't allege something unless you've got evidence to support the allegation.
Gleam, it's been alleged that you're a monkey-eating child pornographer who had a homoerotic relationship with President Bill. But, of course, that's just speculation.
Moral of the story: if you're going to allege that the Andover/VA staff has undue editorial influence, then for Pete's sake, show some evidence to back up your allegations.
And...what about the guy who posted to the original merger (VA-Andover) thread, from valinux.com, who got an automatic +4(!), without any moderation. Hmm.
I'm a certifiable Karma Whore; when I make posts they start out automagically at 2. This is kind of a cool thing. And y'know what? The other day, I saw one of my posts had a score of 1, with no moderation attached to it! My God! My evil nemesis must be out there, maliciously dropping my scores without moderation!
... or it could just be a bug.
Never attribute to malice what can easily be explained by random chance.
Am I concerned about VA/Andover and potential risks to Slashdot's editorial integrity? Yes, I am, and because of it I'm going to be watching the site closely. If I ever find real evidence of editorial malfeasance, then I'll take my marbles and play elsewhere.
This is, incidentally, exactly what Taco, Hemos and everybody else on staff wants. They want the users to keep them honest. As long as we keep our eyes open, Slashdot will keep its editorial integrity. Then Slashdot gets what it wants (our viewership) and we get what we want (News for Nerds, Stuff that Matters).
But there is a significant difference between keeping our eyes open for editorial abuse, and a paranoid belief that the few minor things we're seeing are just the tip of an iceberg of evil.
This is another example of governments using a sledgehammer where a scalpel is more appropriate, and in the process are bludgeoning everyone to death except their lawful targets.
Information security is a reality nowadays. Want to browse the Web securely? Use https (but don't forget to verify the certificates). Want a secure remote login? ssh. Want to keep your EMail safe from prying eyes? That's why God (er -- Phil, I guess) gave us PGP. Want a secure VPN? IPsec.
The tools exist, and when used properly these tools are guaranteed to give the signals-intelligence agency of your choice a migraine headache. (Notice: using the tools properly is hard. It's far easier said than done, but it can be done.)
People who use the Net to commit crimes (or as an aid in committing the same) are probably tech-savvy enough to (a) know they're being monitored and (b) to use these tools. So I don't see that this Draconian measure will have any significant effect on computer crime.
It will have a chilling effect on the communications of law-abiding citizens who are not tech-savvy, though. As a rule, they either don't know these tools exist, don't know why they should use them and/or don't know how to use them -- so they get their civil liberties raped over a cheese grater, all in the name of apprehending criminals who are smart enough to use basic information-security techniques.
Slashdot Mirror
1. YOU DON'T KNOW AS MUCH AS YOU THINK YOU DO.
Nobody does. This is the first and most important rule of software engineering; most badly engineered projects I've seen got that way because people thought they knew more than they did, whether on the engineering, managerial or executive level.
Mark Twain said that what people don't know rarely gets them in trouble--what gets them in trouble is what they know that ain't so.
2. GOOD DESIGN CANNOT BE TAUGHT.
Good design is kind of like skydiving--it can't be taught. You don't really know beans about skydiving until you're headed toward the ground at terminal velocity, fumbling around for the D-ring (or lollipop, or throw chute, or what-have-you for your particular parasail). At that point, it all becomes crystal clear in the way that only being confronted with imminent mortality can make things.
Software design is much the same way. You don't know beans about software design until you're actually designing. See a project through from conception to fruition, and then take a look back on it. If your first experiences with real software design are anything like mine were, you'll be embarassed that your name is on it.
3. GOOD SOFTWARE IS GREAT, BUT BAD SOFTWARE TEACHES YOU MORE.
It's always nice to make software that doesn't suck, but you don't learn very much from doing it right. You learn from screwing up, then assessing your screw-ups and making different choices in the future.
4. THE BEST WAY TO LEARN SOFTWARE DESIGN...
... is by doing it. Find your itch and scratch it. Sit down with a notebook and sketch out how you think it should work, then sit down and code the monster. With luck, your design will suck. Print out your code, compare it against your design, and see where reality fell short of your goals.
Then re-code the monster. Make different choices this time; see how much more (or less) elegant your code appears.
Repeat this process ad infinitum until you get some code that you're moderately proud of. At that point, move on to a different project and start over again.
Before too long, you'll find your design skills improving by leaps and bounds. Remember: your goal here is not to make perfect software, but to learn about software. Don't be afraid to experiment, to fiddle around, to intentionally break your software just to see how it falls apart.
And finally, the most important rule:
5. HAVE FUN!
First off, there is no war. There is no conflict. Hell, there isn't even competition for mindshare, since all of the great KDE apps get GNOMEified in short order and the great GNOME apps get QTified in short order. It's possible that in the future this will cease to be the case as GNOME and KDE focus on not-entirely-compatible technologies (GNOME uses CORBA, while KDE is moving to a more lightweight toolkit), but for right now it's the case.
:) Find me a benchmark which says KDE is slow and I'll find you one that says GNOME is slow.
1. SPEED AND RESOURCE USAGE.
Benchmarks are lovely things; there are so many results you can choose to get.
2. INTEGRATION BETWEEN APPS.
Oh, yes, we've seen in Windows 98 how integration between apps is always to the benefit of the end-user. (Note to KDE fans: I'm not comparing KDE's level of uniformity to Windows' sickening degree of the same. I'm just pointing out uniformity and integration are not the be-all of environments.)
There's a wise proverb about "a foolish consistency is the hobgoblin of little minds", or something to that effect. Consistency is good up until it becomes a foolish consistency, at which point it becomes horrible ("WTF does Microsoft mean, it's `intuitive' to view my hard drive as a freakin' webpage?!"). Does KDE have a more consistent look and feel? Yes, I'd agree that it does. Is this a selling point? Personal preference. To me, it's a nonissue.
3. APPLICATIONS AND DEVELOPER SUPPORT.
Both environments are breaking out all over with new applications and new developers. Last year I had to special-order Dallheimer's Using QT and Harlow's Developing Linux Applications with GTK+. This year there are far more books on the shelves relating to both environments. They're not on the bookshelves for their own sake--they're on the bookshelves because people have been asking for them, and because people are buying them. That shows more than anything else that both are alive and quite well.
4. KDE IS MORE FAMILIAR.
Only if you've got a lot of experience using KDE or Windows. Remember: a foolish consistency is the hobgoblin... If GNOME thinks they have a better GUI, then they should put that forward. If the GNUStep people think the OpenStep interface is the be-all end-all of GUIs, they should put that forward.
Horse-and-buggy transportation was much more familiar to people at the turn of the century. Should I take it they were all fools to abandon the system they knew to experiment with the newfangled, crochety, prone-to-breakdown Model T?
5. HONORABLE MENTION IN THE FUD CATEGORY
"[The GNOME developers] seem to think that putting the biggest, most memory hogging features into the DE will automatically make it better..."
If you didn't bother to read the press release, GNOME 1.2 takes up fewer system resources.
"Software size and quality seems to not be a very top priority, and software speed seems to be an even lower priority..."
Strange. Most of the GNOME apps I've seen are pretty modest in their memory footprint. Insofar as quality goes, I've never had any complaint.
"Features seems to head the list, and everyone knows what that mentality gets you... it gets you Windows 2000."
GNOME is not about features. Making that assertion shows that you really don't grok the free software movement at all.
GNOME is about choice. Don't want to use Gnome Terminal? Great, use Powershell. Don't want to use Powershell? Fine, use an xterm.
First, I am not attempting to come down on either side in the "you can't do OO in C" war. Fact is I think you can, but for a lot of reasons I prefer C++ for OO.
:)
Functionally, OO in C requires you to construct each object manually. This, by itself, is a major pain in the hind end. You wind up having to write code to initialize each new object (big deal--you have to write it in C++, too), and you have to remember to call each initializer.
Destruction is identical but in reverse. Unless your object is pretty trivial, you've got to remember to free those valuable system resources.
It's also difficult to do data hiding in C. In C++, you can declare things to be safely inside the black box, away from the grungy hands of the hackers who don't understand your code and whom you don't want futzing around with your code (and sometimes that grungy hacker is you, six months later, doing something hare-brained and stupid because you've forgotten some small detail). In C++, we've got lovely words like "private" and "protected" to help keep us from shooting ourselves in the foot.
There's foo, bar, baz and quux as well as construction, destruction and data hiding. The fact of the matter is that OO in C is definitely possible, and does not need to be an ugly hatchet job. You can have beautiful, elegant OO code in C.
Remember that the first C++ "compilers" were really preprocessors (anyone remembet AT&T's cfront ?), which took a C++ source file and mangled it down into OO C.
OO in C is gruelingly difficult; I always forget to explicitly call my destructor functions, for instance. C++ has better support in the language for OO code, which is why I'm a C++ hacker more than I am a C hacker nowadays.
It would appear your paranoia is aimed far too specifically: paranoia at our profession being shaken up, perhaps fundamentally.
.5. It does not magically compromise everything. Breaking a 256-bit cipher with quantum computation is as hard as breaking a 128-bit cipher with a Turing machine.
I like fundamental shakeups. I consider the invention of quantum cryptography to be a far more interesting shakeup than quantum computation. Even quantum cryptanalysis is more interesting than quantum computation.
Theoretically, quantum algorithms can test all of the potential factorizations for a key of arbitrary length at once.
You confuse `theory' with `practice'. In theory, a massively parallel Turing machine can compute all of the potential factorizations at once. In practice, we don't worry about this--why? Because it's not going to happen, and we've got a lot of mathematics and physics to back us up.
How many electron energy states are there? That number is on some level fundamentally connected to how much computation can be done--every state corresponds to a different aspect of the number-crunching. There are a finite number of energy states; there is a finite amount of computation a quantum computer can do.
At a conference recently when a paper was presented detailing the latest results of quantum computing, Schneier was heard to mutter "well, gee, any RSA modulus less than three bits is in real trouble..." Will quantum computers get better? Yes--up until about 15 qubits in length. At that point, our current models break down and we're going to have to invent entirely new technology.
Currently, we have absolutely no clue--not even well-thought-out theoretical models--of how to proceed from the 15-qubit level.
All of our algorithms which rely on the difficulty of factoring arbitary prime numbers will suddenly be completley useless and obsolete.
Yadda yadda yadda. I've heard "The Death of Public-Key" for twenty-five years, thank you--yours is nothing new. To factor a 3,072-bit RSA modulus, you'd need something on the order of a 1,536-qubit computer.
That's right. 1,536 qubits.
Even assuming that quantum computation follows a modified Moore's Law and our qubits double every 18-24 months, we're still looking at 15-20 years.
Let me repeat: I am not worried.
Of course, quantum coupling provides a possible solution in the form of an unbreakable one-time pad, but how this can be applied to problem sets which public key/private key encryption addresses remains to be seen.
Quantum computation does not provide any kind of unbreakable Vernam cipher. Quantum cryptography permits secure negotiation of symmetric keys over insecure lines of communication, but that's in no way related to the Vernam cipher. What the heck are you talking about here?
If and when quantum computing does become feasable, security as we know it will be turned on its head, and keylengths of whatever length will be compromized, regardless of your level of paranoia. The entire paradigm will be obsolete, and the entire security infrastructure will have to be rethought from the ground up.
Quantum computing is already feasible. The first electronic computers were used to break fairly sophisticated mechanical ciphers, and they had far less computing horsepower than your alarm clock today. When a wildly divisive technology is introduced, its repercussions are seen and felt almost immediately--look at how much digital computers have overturned our world in the last fifty years.
Quantum computers are not an "if and when" proposition. They are feasible, right now, albeit in a very limited state. So is Leonard Adleman's biological computing paradigm. Both of those have the potential to be incredibly disruptive to whatever fields of CS haven't thought of its ramifications.
keylengths of whatever length will be compromized
Oh, give me a break. Look this stuff up--it reduces the keyspace by an exponential factor of
I am an InfoSec professional in real life, but I am not speaking in my professional capacity here.
.5--that is to say, a keyspace of 1,000,000 elements gets pulled down to 1,000 elements. This sounds like a lot, and it is; being able to take the root of the keyspace is a big achievement for some sorts of computation.
If quantum computers ever come to the forfront, security as we know it today will be a thing of the past..
Poppycock. The theoretical ramifications of quantum computers have been well-known for many years now, and there's been a lot of good academic research on exactly what quantum computers are capable of. They will be neat toys when they arrive, but they will not mean the end of security as we know it.
Put bluntly, using quantum computers you can manage to cut the keyspace by an exponential factor of
Crypto is not necessarily one of them. One of my current clients is concerned about quantum computers being invented and fielded in the next twenty years. So what we're doing is figuring out what sort of keyspace could be reasonably searched in 20 years (assuming a steady progression of Moore's Law), then moving one step past that... and then squaring it.
To give you an idea, 256-bit ciphers will be immune to brute force attack for as long as we're living in the Solar System. Do the power analysis on it; to break a 256-bit cipher by brute force using quantum computers requires an amount of power which borders on the absurd.
Now, that being said, any kind of serious projection about "how much key is enough" is preposterous, especially once you get past five years in the future. That only underscores the ludicrousness of your "security as we know it will be a thing of the past" statement. Security professionals already assume that the opposition has access to ten billion quantum Turing machines. We're paranoid. We're professional paranoids.
Am I concerned for what quantum tech will do to crypto? Yes. Am I shaking in my boots over it? Not hardly.
1. ENGINEERING IS A SOCIAL SCIENCE.
Yep, that's right--it's not a hard science like mathematics or physics except in the most facile and shallow way. Every engineer should have a background in human factors as well as scientific ones. Our creations are ultimately used by human beings, and we cannot afford to neglect them.
2. ENGINEERING IS AN ART FORM.
Engineering is not simply "creating stuff that works". While possible, it hardly contributes to the human race as much as aesthetic qualities like grace and elegance do. Compare an I.M. Pei or Frank Lloyd Wright building with a Soviet-era fish cannery--which one do you think adds more to the world's culture, designwise?
3. SOFTWARE ENGINEERING IS A HIDEOUSLY BROKEN FIELD.
The axiom is that "if carpenters built homes like we build software, the first woodpecker would destroy civilization". No other form of engineering permits the kind of widespread failures and bass-ackwardness which we do. Most Professional Engineers I know (the people who get to add "P.E." after their name) can't stand the thought of programming being elevated to the level of an engineering discipline, because they see us--correctly, for the most part--as Johnny-come-latelies who are concerned only with making a buck and looking cool, not building things which will stand the test of time.
4. MY GOALS
My goals are formed by these principles. Number one, my ultimate and overarching ambition is to make software which is helpful to society and individuals. Second only to that, my goal is to make elegance an integral part of my work. Third, I aim to write software which doesn't suck.
As long as my job permits me to do all those three things, I'm happy. If I write a piece of software which manages to achieve all those things, I'm happy. Right now I'm polishing up Fishtank-1.0.1 for release (a GPLed, elegant, well-documented crypto library; email me if you want to see a pre-release) and I think it's been guided by those principles. I'm happy with it, and that leads to my final, most important, goal:
5. BE HAPPY.
:)
<SOAPBOX>
RMS is unquestionably brilliant, but he is not always right; and while I have the utmost respect for his free software ideals, I have extreme difficulty with the zealotry which some of his supporters demonstrate.
Your first assumption is that Linux developers are not Linux users. You assume that a commercial software company's programmers aren't going to give half a damn about the operating system; you assume they're heartless, faceless, interchangeable capitalists.
News flash for you: every one of those assumptions is faulty.
The people who code under Linux, whether it be for pay or for the good of the community, are going to be familiar with Linux and the community spirit which it was built upon. When you demonize the commercial software developers, guess what? You're demonizing people you should be evangelizing to. Your approach is no different from that of any of thousands of fundamentalist Christians who loudly scream that homosexuality is evil--regardless of whether it is or not, it alienates the very people you're trying to reach.
Your second assumption is that it is an us against them situation. How can I put it bluntly?--I consider this to be a sign of immaturity. RMS may well see the intellectual-property issue in black and white, but he does not see people in terms of black and white. He has more wisdom than that.
Your third assumption is that our rules are better, high in fiber, low in saturated fat, and guaranteed low sodium. While I'll be the first to trumpet the virtues of free software, we will not achieve world domination by means of xenophobia. Without exception, every culture in history which has practiced isolationism has had its butt kicked by the cultures which did not. Do you really want the free software community to get our rear end handed to us on a platter? That's what this kind of isolationism and xenophobia will do, make no doubt about it.
If I were a Windows developer who was considering porting something (like, for instance, let's say a science-fiction MMORPG to Linux) I'd take a look at your post and say "good grief! What a strange person. Well, Marketing says there's a contingent of them who will buy games anyway, so I'll just ignore all of these Linux zealots!"
As soon as that happens, you have forever lost them to the cause.
Commercial software will not be the demise of Linux. Linux is bigger than that, and more importantly, the community is stronger than that. The only thing that can kill Linux--and destroy free software--is the community surrounding it.
And you're doing ten times as much to destroy free software as any closed-source programmer is.
</SOAPBOX>
</SH!T_KICKING>
A bunch of idiots with guns are not going to be able to overthrow the army of the greatest super power in the world. Even if there are a million idiots. The idiots dont stand a chance against tanks, machine guns, planes, and other high-tech high-damage weapons of the military. So this reason seems absurd.
:)
The Romans at Cannae...
... The British at Isandhlwana...
... The French in Indochina...
... The Americans in Vietnam...
... The Russians in Afghanistan...
... and again in Chechnya...
I'll wait while you go look up the history required to realize that guerilla movements originating from an armed citizenry have this annoying habit of wrecking even the best-trained and equipped armies.
I'll try as best as I can to answer your questions. Again, remember: IANAL.
.45, I had to present the county sheriff with a copy of my lease agreement (to prove I was a resident of the State and county from which the permit would be issued), my driver's license and passport, I had to be fingerprinted, I had to wait a month, and I was interrogated for half an hour by the Sheriff (he said he just wanted to make sure I could handle difficult social situations without losing my cool). After going through all that, my permit was issued to me--but at any time the Sheriff likes, he can revoke my permit to purchase.
:) I already answered your question in part. To summarize, it is extremely clear that the Second Amendment is not meant to preserve the right of the nation to create an FBI or Army, the States to create State Troopers and National Guard, or communities to create police forces.
:)
Registration of firearms in no way infringes anyone's ownership of a firearm as long as anyone could register a firearm.
The problem is that no other right enumerated in the Constitution requires registration in order for its exercise. The courts have ruled that it is forbidden to require registration to run a newspaper; it's forbidden to require registration to run a church; it's forbidden to require registration to keep the Army from quartering soldiers in your home.
To phrase things in Net terms, registration is an "opt-out" system. It's the Government saying "we're going to deny you this right, unless you specifically inform us that you intend to exercise it".
The Federal courts have historically been extremely harsh when the government has tried these things. If the courts let the government require registration for the exercise of the Second Amendment, then there is no lawful reason to prevent the government from requiring registration for the exercise of the First Amendment.
There are laws on the books requiring permits for large assemblies of crowds. These laws have been upheld only so long as they impose no significant inconvenience and they exercise no prior restraint. That is to say, the permits have to be issued extremely quickly, and the government is not permitted to deny permits to any organization. This is not the case with firearms registration. When I purchased my
That counts in my book as a significant inconvenience and an unlawful Government control over a Constitutionally-protected activity. It isn't at all in the same ballpark as permits for large assemblies.
There was a case recently in which the Court decided that the right to assembly didn't include the right to anonymously assemble (thus requiring large Klan gatherings to be hoodless), and I'm still trying to decide how I feel about that.
So what is meant by a well-regulated militia? It may refer to groups organized by states or communities and drilled for the common defense of the people.
If you'd read my previous post, you'd have noticed the references to "select and elite corps".
Exactly what the "well-regulated militia" means is still being hammered out in court. Check out Emerson v US, coming out of Texas.
Also, the Supreme Court has frequently curtailed "rights" given by the Constitution to "the people". Free speech, rights to a jury trial, rights of a defendant to confront their accusers, unfair seizures, etc.
Not in recent years. Lopez v US put significant restraints on Congress' power to pass law, for instance. Free speech has consistently been upheld by the Supreme Court; the right to a jury trial has never been abrogated, to the best of my knowledge; the right to cross-examine has been sacrosanct. The seizure provisions of the IRS and drug code may be morally repugnant, but I am unable to provide Supreme Court citations which affirm their Constitutionality. I strongly suspect that if they ever go to the Supreme Court, that the Supreme Court will strongly and viciously cut them down on Constitutional grounds. If I were the United States Solicitor General, I'd live in quaking fear of the grilling I'd get from Scalia or Thomas on those issues.
If you're going to rake the Court over the coals for being asleep at the switch, then you're going to have to provide me citations. On the whole they do extremely good work; the problem is that Congress churns out laws by the thousands and the Court can only give in-depth review to a few dozen cases per year.
If you want more bios on Federal judges, by all means--go on and read their bios. Almost all of them have bios available on the Web. You'll find that a great many of them are former beat cops; FBI agents; soldiers (oftentimes from Special Warfare branches, like the Rangers and SEALs). Until you actually go and check out their bios, please don't tell me they're unqualified.
I make no claim on whether or not short-barreled shotguns have a purpose in home defense or in military use. Short-barreled shotguns have been used in military service as far back as the Civil War; even farther back, all the way to Major Robert Rogers, if you're willing to accept shotgun-style weapons (blunderbuss, etc.).
However, the defendant in Miller did not introduce those historical facts into the court record. It's very possible that, had Miller been wise enough to introduce those terms, the Court would have decided other than they did.
The Court only determines cases based on the facts presented to them. The burden is not on the judge to be an expert in every respect of every discipline of study; the burden of the judge is to be able to learn quickly, very quickly, and to let all parties at trial educate him/her in the discipline in question.
Look at Judge Thomas Penfield Jackson, who had no technical experience before the DOJ/MS trial, and how technically astute his Findings of Fact were. Although there were some shortcomings, on the whole he grasped the subject matter very well. This surprised the court commentators to no end, but it came as no surprise to me--I've seen firsthand just how rapaciously judges learn new things.
I'm done debating this subject now; I don't think you're bringing up any new or interesting points here.
In a nation governed by laws, who else is going to determine how the laws apply besides judges?
I also dispute your underlying assertion; namely, that judges have no background in firearms and/or military conduct. I know of one Federal judge, one small step below the Supreme Court, who served as an Army Ranger in the European Theater in World War Two and participated in the D-Day invasion. Another judge I know is a retired Navy SEAL from the Vietnam era.
Personally, I think either of those two would have almost ideal qualifications to judge which weapons are deserving of Second Amendment protections and which are not.
(Went white-water rafting with the SEAL in '91. You could tell he was a SEAL... he jumped out of the boat just before the waterfall, just for kicks.)
No, I'm not going to tell you who they are. They both operate in the 8th Circuit. If you're really interested, you can check the bios of all the Federal judges in the 8th Circuit and find out exactly which two I'm referring to.
Under Iowa law (interesting fact--yes, I am a citizen of Iowa and yes, this law is still on the books), as an armed citizen of fit body and legal voting age, I am a member of the armed citizen militia.
The last time I had to use a gun to preserve the security of my free state was August, 1998. Someone was being beaten to death by a teenager with a tire iron. I called 911 and grabbed a shotgun. The perp decided that my 12-gauge beat his tire iron both in damage and in range, and he made the intelligent, rational decision.
No shots were fired, and for that I will always be deeply thankful. Most frightening experience of my life, let me tell you. Afterwards I had the shakes and vomited myself into the dry heaves.
IANAL, but I do follow the Bill of Rights pretty closely and have performed a fair bit of scholarship on the issue. In the spirit of disclosure, let me say that I possess three firearms and I enjoy participating in the shooting sports.
The overall intent of the Second Amendment is clear: that the citizenry is meant to possess the right to bear arms for the defense of themselves and of the community. This view is fairly universally shared by everyone in the gun control debate, save for those few who claim it only protects sporting purposes. (I cannot grant any credibility to these claims; in all my scholarship on the Bill of Rights, I have never found any hint from any of the Founding Fathers which suggests that any portion of the Bill of Rights is meant to ensure continued sporting activity.)
The real interesting portion comes in how you interpret that original intent. The more militant members of the pro-Second Amendment community (such as the poster I'm originally responding to) claim that all gun control is illegal; the more militant members of the anti-Second Amendment community (such as Sarah Brady) maintain that guns are inherently regulable.
Neither opinion is, in the opinion of the Supreme Court of the United States, worth a bucket of steaming excrement.
The pro-2A crowd fails to notice US v Miller (I think that's the proper cite), where a man convicted of possessing a sawed-off shotgun appealed to the Supreme Court on grounds that it unlawfully violated his rights. The Supreme Court said that it was unable to see how the possession of a sawed-off weapon contributed to the "well-regulated militia" and therefore received no Second Amendment protection.
Sarah Brady and HCI take US v Miller as proof that all weapons are subject to regulation. This is incorrect; a reading of US v Miller indicates that only those weapons which serve no useful purpose to a well-regulated militia can be arbitrarily regulated. In a strict interpretation of the Court's decision, Miller is actually a vindication of the Second Amendment in that the Court comes very close to outright stating that weapons with military applications (such as fully automatic assault rifles, etc.) possess Second Amendment protection.
So. According to Miller, weapons are regulable if they possess no utility to a militia. It's not as clear a victory for the anti-2A crowd as they make it out to be, and it's not a defeat for the pro-2A crowd, either.
That's the most recent Supreme Court cite which addresses the original poster's "all gun control laws are unconstitutional" argument. Now to take the flip side:
The anti-2A crowd likes to forward the idea that the Second Amendment is a collective right; that is to say, that the use of "the people" refers to the State or Nation as a collective whole and not the people individually. This fails both legal and historical tests.
Legally, to interpret the Second Amendment's use of "the people" in a collective sense would force the Supreme Court to interpret every other instance of "the people" in the Constitution similarly. The Court has refused to do this on multiple occasions, and as recently as a few years ago has referred in passing to the Second Amendment as a right which belongs to individuals.
On the historical side, George Mason (I believe) famously stated "Who, then, is the militia? Now it is the whole of the people." That by itself is a fairly clear statement from the Founding Fathers; considering that no-one at the convention spoke after Mason to condemn that assertion, we may assume it enjoyed widespread popularity.
Moreover, national and state militias composed of citizen-soldiers were known to the Founding Fathers. They were referred to as either "elite corps" or "select corps", depending on which authority they were chartered under (ref: Tennessee Law Review. If the intent was to guarantee the national and state rights to assemble armies and National Guard units, the Amendment would have read "Well-regulated select and elite corps being necessary to the security of a free state..."
So the anti-2A argument that the Second Amendment only protects the Army and National Guard units is obviously, blatantly incorrect.
There is still a great deal of litigation going on in an attempt to clarify exactly what the Second Amendment means. For recent Court decisions, I'd suggest you look at Lopez v US, in which the Court found that Congress had overstepped its Constitutional authority by restricting the possession of firearms near schools. This wasn't a Second Amendment case, per se, but it was a clear indication from the Court that it thought Congress had significantly overstepped its mandate.
Also, check out Emerson v US, coming out of Texas, where the Lautenberg Amendment (which strips people of their Second Amendment rights if they have any misdemeanor domestic-abuse conviction or restraining order filed against them) was overturned. In Emerson, a Federal judge found that misdemeanor convictions and restraining orders were insufficient process of law to strip someone of rights guaranteed by the Constitution.
Recently, the murder rate in DC has fallen considerably (or so the statistics say--but then again, considering how easy it is to lie with them...). Still, Washington DC has a reputation for being an incredibly unsafe city in which to live, as well as a city which is incredibly inhospitable to the Second Amendment.
The comment which was made was done in the spirit of sarcasm. A great many people, including the vehemently pro-gun control Mike Royko, have observed that the cities in the U.S. which have the most gun control also have the most crime.
The NRA would like you to believe that gun control leads to crime. Their logic is that with a disarmed citizenry, criminals can commit their depradations without fear of armed reprisal from their victims.
Other organizations, such as Handgun Control, Inc., offer the view that strict gun control laws are passed as a reaction to the lawlessness which widespread gun ownership brings.
I tend to side more with the NRA than with HCI on this issue.
First, your points are spot-on when it comes to C versus Java. When comparing C++ to Java, though, many of your issues go away.
Simplicity: a well-architected C++ solution, which intelligently uses the appropriate features of the language, is just as simple as Java. In fact, Java borrowed most of its simplicity from C++ in the first place.
Threading: Okay, this one is granted.
Garbage collection: Contrary to popular belief, Java's GC isn't exactly the best thing since sliced bread. There's a fairly large industry providing third-party garbage collection tools for Java. Can't remember any of them off the top of my head, but I do know that some of them are wealthy enough to afford full-page ads in Communications of the ACM.
Bjarne Stroustrup has also said that GC will likely be implemented in the next ANSI draft of C++. While that doesn't balance C++ and Java, it does mean that you're comparing no GC in C++ to a somewhat broken GC in Java. Neither one is an optimal solution.
Standard libraries: Are you at all familiar with the STL and free (liberty) C++ libraries? The advantage of Java isn't that it has every function under the sun; it's that the collection which ships with the JDK is very comprehensive. C++'s body of free (liberty) libraries is far superior, but you have to search for them.
I also have a slight objection to your use of the word "standard". There is no Java standard; therefore, there can be no standard library. C++ has been standardized; Java isn't.
Bounds checking on arrays: C++ includes this. It's included this for quite some time. It's not possible to bounds-check a C array, but it's trivial to bounds-check a C++ container (list, vector, etc.).
Printing stack traces from exceptions: Look around the free (liberty) C++ libraries. I'd be extremely surprised if you couldn't find one.
Reflection: C++ includes this. It's called RTTI (run-time type identification).
... I am not trying to denigrate Java or elevate C++. I've used both, and I have no clear favorite between the two. Java borrows very heavily from C++, and it constantly surprises me at just how many Javagrinders say "well, C++ doesn't have features foo and bar!" without realizing that Java borrowed foo and bar from C++.
That said, it is incredibly difficult to become a good C++ programmer. The language is straightforward, but has extremely complex nuances which require years of exposure to fully comprehend. Java is a much more straightforward language, but occasionally the lack of nuance makes it difficult to achieve subtle hackery.
Schneier has a long and very distinguished history of breaking protocols. He discovered attacks against IPSec and Microsoft VPN; I believe I saw his name on a couple of papers breaking various cellular phone protocols.
If you scoff when you hear Schneier called a "security expert", then you don't understand what his credentials are. Is he God? No. In fact, Schneier's been flat-out wrong before (anybody here remember MacGuffin, and his latest campaign against elliptical curve cryptography?).
But to say that Schneier is a crypto expert and not a protocol expert flies in the face of Schneier's body of published work.
How many protocols and ciphers have -you- broken?
Standard disclaimers apply, as always. (I hate living in a lawsuit-happy culture.)
:)
What also might be good is to include protocols which, while working today, are not scalable to future systems. Right now I'm employed by a company working in the electronic publishing market, and it's surprising how many otherwise-good ideas are completely impracticable. (The good news is, the worst offenders are all proprietary. The open systems have fared the best.)
Last year during CRYPTO99, some IBM researchers released a paper which was lauded as having provable security. Caused a minor media uproar, up until it was broken. Turns out that if you can create an environment where just one of the assumptions behind the protocol is no longer valid, the entire protocol fell apart. I can't think of the name of it for the life of me, though. It didn't exactly impress me as being the Holy Grail, and I wasn't exactly surprised when it was broken.
Another good example is Microsoft's Virtual Private Networking. Version 1.0 was horribly broken; version 2.0 was a considerable improvement, but since it was (is) downwardly-compatible with 1.0, it's also bug-compatible with 1.0.
Then there's Netscape's SSL difficulties from version 3 (?). Although the SSL protocol was implemented correctly, Netscape's random number generator was deterministic.
Then there was the telco which was using the standard C rand() function to create random session keys (company name withheld, but yes, it's a big one).
A major credit-card company (you probably have one of their cards in your wallet) depends on nobody being able to break repeated-XOR encryption and having enough knowledge of IBM's SNA in order to eavesdrop on their network.
... I don't know as much about academic protocols being broken through the standard literature as I do about brain-damaged implementations of protocols. I'm a practical cryptographer, not a theoretical one. But good God, if you were to make a top ten list of the stupidest protocols (and implementations thereof), you'd spend years just trying to whittle the list of thousands of candidates down to the ten worst.
I don't know. I'd have to think about it for a while to come up with my own list of candidates for the Provably Stupid award. Ask me again tomorrow and I might have a better idea.
I am an InfoSec consultant in real life, but I am not speaking in any professional capacity here.
First, I've got to say that I'm glad that someone has come out with a companion to Applied Cryptography; where Applied Cryptography talks about ciphers in some detail, it's woefully light on protocols--and most of the interesting security attacks out there are protocol attacks, not cipher attacks. If the review posted is accurate, then we can use it as an adjunct to Menezes and Schneier, not as a replacement. This is a Good Thing(tm).
Second, for all that I'm looking forward to buying this book, I think that it ignores a very rich and informative part of the subject. Why not take a book of the same size and cover failed protocols, and explain where the protocols failed and why? I like to joke that there are only three or four different protocol attacks; software authors just insist on renaming them for every new system. An awful lot of good could be done by educating software engineers about what has failed, in the hopes that people will learn and not make those same mistakes again.
I'm grateful to Bruce Schneier and Alfred Menezes for their introductory works in crypto (and compared to graduate-level mathematics, Schneier's and Menezes' books are introductory), but I sometimes fear that they lull software engineers into a false sense of security; people think that "well, since Schneier says 3DES is secure, I can just use that and be safe". It's very tempting to do that, but security is not something which can be added into a piece of software like you can add salt to a recipe. It is a mistake to take a cookbook approach to security, which is the unintended consequence of books such as these.
What I'd really love to see is a book which shows failed protocols, and the dangers of cookbook security.
Having a cookbook available doesn't guarantee that what you cook will be edible.
I am a professional InfoSec consultant, but I am not speaking professionally here. This is not my professional advice.
Don't encrypt passwords, hash them!
Hash algorithms are intimately related to encryption algorithms; so much so, in fact, that you can take any iterative block cipher and turn it into a hash. Just run it in CBC mode with a fixed key and IV, and your last ciphertext block becomes a hash of the algorithm. The hashes which are produced with most block ciphers are weak, but that's because most block ciphers today use 64-bit blocks--64-bit hashes simply aren't big enough. Using an algorithm like Twofish or Rijndael (both AES candidates, which have 128-bit block sizes) allows you to create a modestly good hash algorithm.
That said, dedicated hash algorithms are likely going to be stronger than strong crypto converted into a hash algorithm. It's just as much of a fickle art to craft a good hash algorithm as it is to craft a good encryption algorithm. Ron Rivest is (rightly) hailed as a brilliant cryptographer, but he's still yet to make a uniformly strong hash algorithm. (MD5, while still in wide use, has some vulnerabilities; while it's secure enough for most purposes, it is not -uniformly- strong. Even the NSA has problems, as demonstrated by how quickly SHA-0 was abandoned for SHA-1.)
An interesting login scheme that I've heard of is ridiculously simple. Have a user send a timestamp to the server, signed with their asymmetric public key. The server attempts to check out the signature; if it passes, great, the user is authenticated. It's not perfect by any stretch of the imagination--it's vulnerable to all the attacks presently existing against asymmetric cryptography, and probably has another vulnerability or two in there somewhere--but it's an interesting and simple solution to the problem.
Due to a bug in Slash, the message directly above this in the thread (BAYWATCH.JPG) was attached as a response to the wrong message. A newbie was asking a question about multiple encryptions in weird and unexpected ways, and whether or not it could provide security. So please--hold the flames, I really *did* respond to the right message, honest. :)
A bug report has been filed with Taco.
Here's what I'd do in order:
.JPG. Wow, guess what, it's not a .JPG... must be something else.
... another ZIP file! Well, damn. Smack it around with the Perl script once more.
1. Try and display it as a
2. Look at the first few hundred bytes of the file. Almost every distinctive filetype out there today has distinctive header information. Standard compression libraries (PKZip, zlib, etc.) have very well-known headers.
3. Try to unzip the BAYWATCH.JPG file. Hey, it's asking for a password. Damn.
4. Leaf through my notebooks to find PKZip's encryption algorithm (it's trivially weak, but I don't remember its implementation off the top of my head).
5. Ah ha! I've found the cipher that's used in PKZip. Now I've just got to write a Perl script that'll break the cipher--it is a trivially weak cipher, after all.
6. Presto. Now I've got the original file back, or so I think. I take a look at it with a hex editor. Hey, this is
7. Check the file again. I've suddenly got the secret recipe for the $250 Neiman-Marcus cookies. I hand over the fruits of my labor to Boris and Natasha in the hopes that they will use these cookies to lure the moose and squirrel to their doom.
... Looking through the chain, you've got some file (FOO.BAR) which you compressed using PKZip (FOO.ZIP). You ran it through uuencode and uudecode (net result, no change), leaving it as FOO.ZIP. Then you just compressed-it-with-password again and renamed it BAYWATCH.JPG.
Total time for me to break it--six hours. That includes time to write the Perl script to break PKZip's encryption (provided I don't already have one somewhere), time to debug the Perl script, and enough time to order a pizza and have a decent lunch while I work.
If I've already got a Perl script to rip PKZip's encryption, then figure it'd take me about fifteen minutes.
What I want to say is: if you are smart enough to leave no traces (or better yet, lure the crackers to a wrong trail), could even a 'mediocre' encryption algorithm (or combos thereof) be 'secure enough'?
... I hope this post answers your question. The short answer is "no". The long answer is "usually, no".
Although I am a professional InfoSec consultant in real life, my opinions expressed here are not to be interpreted as my professional opinion. (There. Now that the legal disclaimers are done...)
1. ECC is not patent free. Several companies are engaged in patent war over ECC (Certicom being the number one). The "nice" curves have already been patented (mathematicians in the audience will crucify me for describing some curves as "nice", but it's a reasonably accurate layman description--some curves make crypto easier than others, hence they're "nice").
2. ECC is not faster than RSA. RSA is not faster than ECC. Nor are they equal in speed. While this all sounds terribly contradictory, it's all true; as we all know from having complained about NT-versus-Linux benchmarks, whoever is paying the analysis firm gets the results they want. When Certicom pays for ECC-versus-RSA, it always turns out that ECC is faster. When RSADSI pays for it, it always turns out that RSA is faster.
Even assuming that ECC were unambiguously faster than RSA, it wouldn't make a tinker's dam of difference. The applications which use asymmetric cryptography extensively are few and very far between. Symmetric ciphers have a better foundation in number theory, are more thoroughly cryptanalyzed and are often faster. Most of the time when asymmetric crypto is used, it's only used to negotiate a symmetric key. If it takes RSA a millisecond to encrypt/decrypt a 256-bit Twofish key, what do I care if it takes ECC a microsecond to do the same task?
3. RSA smartcards have existed for years. Check out the iButton for an example of how asymmetric cryptography can be used in smartwear (jewelry, buttons, etc).
Insofar as Schneier's distaste for cracking contests, I've got to say I'm in the same boat. Running a cracking contest doesn't prove anything. It doesn't prove it's secure, brute-force cracking rarely betrays insecurities, and what it's best at is media hype. PHBs the world over look at cracking contests and say "Wow, ECC stood up really well to that distributed attack, I guess it's safe for us to use!", without even once bothering to learn what the theory behind ECC is.
Schneier himself uses contests, so it's disingenuous to suggest he claims contests have no value. Schneier's Blowfish contest offered a cash award to the best cryptanalytic results against Blowfish, regardless of whether or not those results led to a break. That seems to me to be a more healthy way to run contests, although I'm still not entirely sold on the idea.
First, I am a professional information security consultant. Second, no, this is not professional advice; do not rely on it without first verifying.
However, unlike DES, there is no known mathematical loophole
Wrong answer, thank you for playing. DES is one of the most, if not the, most thoroughly-analyzed ciphers of all time. So far, the best way to break DES is by a brute force attack. There are some attacks against it which some people use as proof that the NSA put a backdoor in it, but these attacks are extremely esoteric -- for instance, the key complementation property means you only have to test half the possible keys; this reduces the difficulty of some attacks (chosen-plaintext attacks, specifically, although I think Eli Biham has a known-plaintext version) by a factor of 2--meaning the keyspace is only of size 2**55, not 2**56.
The rules for using DES are simple. Don't use weak keys; don't use complementary keys; use it in DESede (aka TripleDES) mode. The resulting ciphersystem is as close to unbreakable as you're likely to ever get. If your system is eventually broken, you can be reasonably certain that the cipher was not the subsystem which suffered the breach.
I trust DESede more than I trust Blowfish, more than I trust IDEA, more than any other symmetric ciphersystem out there.
Interestingly enough, so does Schneier. A few months back at a crypto conference someone in the gallery asked him what the strongest cipher today was. As I recall, his words were "Triple DES. There is no question."
Weeeeellll... since VA and Andover are both publicly held, their administration can't do anything that doesn't benefit the stockholders financially. If they *do* do that, they'll get their pants sued off, and lose their jobs.
... well, you'll have to ask Id and Bungie.
Not true. Corporations do things which are adverse to profit all the time. Sometimes it's more accurately a case of putting off short-term profits for a long-term gain, or sacrificing long-term profits for a short-term gain. Or sometimes it's just because they think it's the right thing to do -- kind of like how some European automakers do not enforce patents on safety mechanisms, because they feel that safety is more important than profit.
Microsoft has long been a significant contributor to the Free Software Foundation. I don't know about you, but I'd consider that adverse to Microsoft's self-interest. (The donations come through the United Way campaign. Microsoft has a pledge to match employee donations to United Way charities, and the FSF is a UW-approved charity.)
Id Software has GPLed Quake; Bungie Software has GPLed Marathon 2: Durandal. While these software products are getting long in the tooth there was still a market for them. These two prestigious gaming companies intentionally forfeited profit, because
Corporations do things adverse to their own financial interest all the time. Claiming otherwise shows a lack of historical knowledge.
I don't have any personal opinion on the merger, except that VA now owns both sourceforge and server51, so the only non-VA free development platform-type-site that I know of is openprojects.net. But that's a different point altogether.
RHAD doesn't count as a free software development site? What about all the websites devoted to kernel hacking? Whatever happened to email?
The Linux community survived just fine before Sourceforge or Server 51. I've made significant contributions to free software projects and I've never even visited either of those two sites.
If Sourceforge and Server 51 were essential to the development of free software, then yes, I'd be irked about one company owning both. But they're not essential, so why worry?
Oh, and themes.org and Slashdot are now owned by the same people...isn't that exciting? But, of course, the Andover/VA Linux staff has no say in what gets posted and what doesn't.
The first rule of journalism is don't allege something unless you've got evidence to support the allegation.
Gleam, it's been alleged that you're a monkey-eating child pornographer who had a homoerotic relationship with President Bill. But, of course, that's just speculation.
Moral of the story: if you're going to allege that the Andover/VA staff has undue editorial influence, then for Pete's sake, show some evidence to back up your allegations.
And...what about the guy who posted to the original merger (VA-Andover) thread, from valinux.com, who got an automatic +4(!), without any moderation. Hmm.
I'm a certifiable Karma Whore; when I make posts they start out automagically at 2. This is kind of a cool thing. And y'know what? The other day, I saw one of my posts had a score of 1, with no moderation attached to it! My God! My evil nemesis must be out there, maliciously dropping my scores without moderation!
... or it could just be a bug.
Never attribute to malice what can easily be explained by random chance.
Am I concerned about VA/Andover and potential risks to Slashdot's editorial integrity? Yes, I am, and because of it I'm going to be watching the site closely. If I ever find real evidence of editorial malfeasance, then I'll take my marbles and play elsewhere.
This is, incidentally, exactly what Taco, Hemos and everybody else on staff wants. They want the users to keep them honest. As long as we keep our eyes open, Slashdot will keep its editorial integrity. Then Slashdot gets what it wants (our viewership) and we get what we want (News for Nerds, Stuff that Matters).
But there is a significant difference between keeping our eyes open for editorial abuse, and a paranoid belief that the few minor things we're seeing are just the tip of an iceberg of evil.
Rant done.
This is another example of governments using a sledgehammer where a scalpel is more appropriate, and in the process are bludgeoning everyone to death except their lawful targets.
Information security is a reality nowadays. Want to browse the Web securely? Use https (but don't forget to verify the certificates). Want a secure remote login? ssh. Want to keep your EMail safe from prying eyes? That's why God (er -- Phil, I guess) gave us PGP. Want a secure VPN? IPsec.
The tools exist, and when used properly these tools are guaranteed to give the signals-intelligence agency of your choice a migraine headache. (Notice: using the tools properly is hard. It's far easier said than done, but it can be done.)
People who use the Net to commit crimes (or as an aid in committing the same) are probably tech-savvy enough to (a) know they're being monitored and (b) to use these tools. So I don't see that this Draconian measure will have any significant effect on computer crime.
It will have a chilling effect on the communications of law-abiding citizens who are not tech-savvy, though. As a rule, they either don't know these tools exist, don't know why they should use them and/or don't know how to use them -- so they get their civil liberties raped over a cheese grater, all in the name of apprehending criminals who are smart enough to use basic information-security techniques.
Gotta love it, huh?