My father used to counsel me that if you've got to spend more than thirty seconds explaining why what you're doing is right... it's probably not. It's been a surprisingly good rule for me, as long as I remember that it's a general rule and not an absolutist statement.
With that said, the important thing is just to boil it down to the simplest accurate moral principle you can find. If I were in your situation, I'd say "A guy is being ripped off by people I'm working for."
Your choices, as near as I can tell, are pretty minimal.
You can do nothing, which most people would do--but the place in Hell closest to the fire is reserved for the people who do nothing.
You can tell the author, in which case you'll have a lot of shit raining down on your head if you're ever found out. The author will have verification from inside the company that his copyright is being flagrantly disrespected, and the author will have the choice of pursuing further action.
Or you can quit. While it might seem noble to fall on your sword, this amounts to "doing nothing". Management won't change their behavior because you quit, or threaten to quit; once you quit, you're out of a job, the original author is still in the dark about the copyright violation and the company gets to keep on doing the unethical thing.
There are other options available to you, but the above three seem to be what all of your options boil down to. Given the above options, I'd inform the author--discreetly and carefully. If I got discovered, I'd voluntarily resign.
I've posted this before, in a different form. But since people keep on making the same boneheaded statement again and again, I have to keep on presenting myself as an Average Joe exception to the rule.
First, I'm not Joe Schmoe from Asshole, Indiana. I'm from a small town in Iowa, which is probably even more podunk than Asshole, Indiana is. And I'm fairly certain I've been under surveillance at least once in my life, and maybe far more often than that.
Back in 1993 I was just getting interested in crypto, and I had an email exchange with a notorious arms dealer who was under investigation by the U.S. Government for arms smuggling. His name was Phil Zimmerman, the guy who wrote PGP. It was an innocuous email conversation talking about large number theory. But realistically, Phil was under investigation for arms smuggling (specifically, violation of ITAR/EAR), so it seems pretty reasonable for me to believe that he was under some kind of surveillance.
Guess what? Since I was talking to him, that meant I was under surveillance, too.
How many of us here have friends who are active in the phreak community? Go on, raise your hands. How many of you believe that your friends are so 1337 that they'll never be caught, never be fingered to the cops by their friends? Wow. So you have 1337 phreak acquaintances or friends, and you think that they might come under police investigation someday?
Well, guess what, buddy. If they come under investigation... so do you.
Loyd Blankenship, from Steve Jackson Games, found this out the hard way. Remember the Secret Service raid on SJG? That was predicated, in large part, on Blankenship's association with people the government declared to be naughty. It was a pretty tenuous freakin' association, too--and the Secret Service still decided to swoop down and raid the place.
In my last job, I was doing InfoSec for a San Francisco start-up which was going to be expanding into Europe. This concerned me, because a lot of European businesses are partially owned by the government, and the European intelligence agencies (particularly France's DGSE) have been known to eavesdrop on communications for purposes of economic espionage. The NSA does the same thing for American firms--but the NSA claims that it only does so to counteract foreign governmental abuses of their intelligence apparata.
Was I concerned about the DGSE? Hell yes. Little ol' me, the hayseed who grew up on an Iowa farm, was working in an industry where governments commit economic espionage.
A few months ago I became tangentially involved in a criminal investigation. Although I wasn't the target of the criminal investigation, I worked closely with the individual who was under the FBI's spotlight. Guess what? That spotlight got pointed against me, too. Not for long, just long enough for the FBI to realize that I had nothing to do with it. But I didn't like it one bit.
We don't have to be important or criminals to come under the spotlight of government scrutiny. We don't have to be doing anything wrong. We can be community leaders, outstanding citizens and decent human beings--and still, if you associate, knowingly or unknowingly, with people which the government is taking an interest in... well, you can expect to get hit.
First, I'm a certified, certifiable cryptogeek, so I'm probably biased here. That being said:
Crypto.
The first rule for teaching (or maybe the second, right after "No matter how much they're the spawn of Lucifer, love the kid anyway") is that you don't have to teach a subject; if you can make the subject something the kid wants to learn, the kid will tear into it with the kind of unholy abandon that only teenagers can muster.
Think about the virtues of crypto, and how you can make your students enjoy it. Make it a point to teach the real stuff, not something watered-down. Emphasize that this is "military-grade" stuff [*], and that nobody--not the NSA, not the CIA, not anyone--can break these ciphers [**].
Tell the kids this, and they'll figure out pretty quickly that there are a lot of things they can do with crypto. Some of them will undoubtedly give your principal gray hair, but hey, that's the price of education. Not as if some of those Satanspawn don't already give him more salt than pepper.:)
There are a lot of ciphers which are fairly simple to sketch out on the whiteboard. I'd suggest Blowfish or RC4; both of them are exquisitely simple in theory, and straightforward in practice. There exists a lot of source code for Blowfish, at least a dozen different implementations in the public domain or Free Software, and RC4 (also sometimes called "arcfour") is almost as widespread.
You'll wind up teaching them about number theory, groups/sets, Boolean logic, the whole nine yards. You could easily spend most of a quarter writing this, and each day in class you'd cover a different aspect of computer science, along with a surprising amount of mathematics.
Crypto is a surprisingly comprehensive discipline. Good crypto libraries require that the programmer have a master-level knowledge of software engineering principles, advanced knowledge of their programming language, and sophistication in how they think about problems.
And when the kids start sending each other PGP-encrypted email over the school network, plotting the violent overthrow of the school and how to best string up their most-hated teachers from trees, you can sit there with a beatific, immensely satisfied smile and say--"Those are my kids."
If you want to know more about crypto and the classroom, feel free to drop me an email. I've got a C++ library for Blowfish which I wrote to teach some younger friends good software engineering principles--it's well-designed, with a boatload of documentation.
[*] Gloss over the fact that there is no accepted definition for "military grade".
[**] Gloss over the fact that there are easier ways to attack ciphers than by cryptanalysis.:)
How much does a private college cost nowadays? The one I graduated from is running around $25,000/yr nowadays. Nonprofit or not, that's a lot of money. It's so expensive, in fact, that the vast majority of students have to get financial aid just to attend school; again using my alma mater as an example, $8,000 a year of my tuition went to subsidize other people's educations. (I was, regrettably, a full-pay student. After graduation the alumni office got in touch with me asking me if I'd be willing to make a donation to the scholarship fund, and I got a little bit irate with them--after all, I donated $32,000 to the scholarship fund over four years and I didn't even get a thank-you note.)
If there aren't enough full-pay students, then there have to be cutbacks in the amount of financial aid the college gives; and if that gets cut back, the college winds up serving fewer and fewer students. And since the cost of running the college is amortized over the entire student body, if the student body shrinks, rates go up--sometimes dramatically.
When I applied at my alma mater, it was considered to be a very selective school. The average ACT score was a 28 or so, and SATs were similarly high. Over the last several years, financial pressures have forced the college to lower its admission requirements until it is no longer a selective college--basically, "if you graduate from high school and you're a full-pay, we will walk into Hell itself if that's what it takes to get you in the door".
Has the academic mission been corrupted by money, and the financial crunch which all educational instututions find themselves in? Damn straight. Is it anybody's fault? Not really, no. It's just one of the big rules of life. Money changes everything; if you have money, you have a lot more options than if you don't have money.
If corporations want to offer education, will the education they offer be affected by their profit motive? Yep. Just like the students they accept will be dictated by their target markets.
But where Metroworks U. might be affected by "if they aren't buying $500 a year of Metroworks products, kick 'em out, and if their OS is a platform which we don't support, don't accept 'em", private colleges say "if they aren't filling our coffers with $X, decline to invite them back for another year."
Nonprofit institutions have to worry about the bottom line, just like everyone else.
Do the power analysis. It requires a minimum of kT energy to flip a bit, where k is Boltzmann's constant (1.38 * 10^-23 joules per Kelvin) and T is the temperature your computer is running at (the background temp of the universe is about 3.2 K).
It would require an optimal computer [*] about 250 megawatts of power [**] and a full year of time to break a 128-bit cipher.
[*] We don't have anything close to this.
[**] 250 Mw is a hell of a lot of power. Don't ask me how you'd keep your computer from melting down from the heat. Or how you'd keep it at 3.2 K, for that matter.
128-bit ciphers are secure for the indefinite future. I don't expect anything short of enormous advances in quantum computation to make a dent in them.
The following is not professional advice. I have not done an audit of Hushmail; I've looked at their code a little bit, along with how they handle messages and encryption.
My impression is that there are some flaws in the design--lack of a security audit, lack of choice in ciphers, possibility of Trojaning, dependence on your browser handling HTTPS properly, etc.--but all in all, Hushmail (click here) seems to be the best option out there right now for secure Web-based email.
I've used Hushmail in the past for email communications with my attorney (she's too tech-naieve to use PGP properly, but she understands "if I send him email at his Hushmail account from my Hushmail account, then I'm doing my part to keep attorney-client privilege secure").
I've got to say that I feel safer with PGP/GPG, but Hushmail is a hell of a lot better than most of the snake-oil that's sold out there.
I'm not saying Hushmail is good; I can't say that, given that I haven't done any hardcore analysis of it. I'm only saying that, based on my experience with it and based on what I've reviewed of their setup and policies, Hushmail seems to be the most clued-in of all the current secure Webmails.
During the years when export of cryptography was illegal, I was habitually encrypting everything crypto-related which I sent to other people via email. After all, the government went after Phil Zimmerman, and once tried to tell a group of mathematicians that they couldn't deliver a presentation on RSA. The government was very interested in export-control, and using crypto on email conversations about crypto was just a prudent way to keep myself safe and lawsuit-free.
Let's also not forget the business world. My previous job was for an Internet start-up which was going to be expanding quickly to Europe and the Pacific Rim. Certain countries (France among them) have industries which are partially or wholly owned by the government; and the governments of certain countries (France among them) have histories of using their intelligence agencies to gather economic intelligence on the competitors of these government-owned industries.
Were we concerned about the DGSE eavesdropping on our plans to set up shop in Europe? Damn straight.
And let's not forget the fact that you don't have to be important to warrant being searched. Let's say that you're a journalist and you're a big nobody. The government doesn't care about you. You're talking via email with someone, using them as a reference for a story, or maybe they're providing you with leaks, or whatever.
Let's say your source is also under investigation for drug smuggling. The FBI can eavesdrop his emails, but that might tip him off. Instead, it's easier to eavesdrop on the emails of the people he talks to.
After all, drug smugglers tend to take extreme precautions with their communications. There's no guarantee that the people they talk to do. It just makes sense.
... I qualify on all three points listed above, you see. I was violating ITAR/EAR before it became fashionable, and I was very concerned about getting a call from the FBI.
I worked for an industry in which we had very real concerns about foreign governments eavesdropping on our electronic communications and giving our secrets to competitors.
And I talk with a few lawyers and a journalist, and in 1993 I had a pretty long set of email conversations with Phil Zimmerman. I know that at least one of those people was under government surveillance at the time, and I don't know about the others.
So your statement--"I don't think anyone reading Slashdot is important enough that the government would want to read through his or her e-mail"--is quite false.
Also keep in mind--in every one of these events, what I was doing was legal. ITAR/EAR was struck down as unconstitutional in its control over computer source code; my business was totally legal; my communications with lawyers, PRZ and the occasional journo are all completely, totally legal.
Just because you're one hundred percent legal doesn't mean the government isn't going to snoop.
Depends on what you're trying to do with it. It's just a tool, nothing more. A hammer is pretty useless when what you need is a screwdriver; same thing with encryption.
If you're sending a love letter to your sweetheart and you want to make sure that it won't get intercepted in transit, encrypting your email is very effective. If you're sending details about your Hizbollah contacts and how you're building a nuclear weapon for them, you probably want more tools than just encryption.
Are we sure they can't break it?
No. Hell, we're not even sure we can't break it. Much of cryptography is built on math problems which are conjectured to be insanely, mind-bogglingly difficult. These math problems have never been formally proven to be as difficult as we think they are, though. Some people think that simple, elegant solutions exist to these problems exist, but so far they're in the minority.
This is not a death-knell for cryptography, though. So far, we're pretty certain that we can't break it by conventional means, and we've got reason to be optimistic that governments can't break it by conventional means, either.
Of course, the government has decades of experience at unconventional means--planting eavesdropping devices, shadowing people, bugging their phone lines, bribing people to give up their encryption keys. Encryption can't really help very much against these unconventional methods.
Now that the USA seems to be relaxing its control over exportable crypto, can we take this to mean that they know they can defeat it?
Absolutely not. Anyone who tells you otherwise is a fool. We do not know what inferences we should draw from the Government's relaxation of crypto regs. What we do know is the following:
1. Federal courts have decided, at the appellate level (one step below the Supreme Court), that source code can be Constitutionally protected free speech.
2. Federal courts have decided, again at the appellate level, that cryptographic documents (whether published conventionally or on the Web) are Constitutionally protected free speech.
The inference that I draw from those two events is...
<INFERENCE>
After losing those two almost back to back, the Government didn't have much choice but to relax the export regs--because the Federal courts had declared the export regs to be unconstitutional!
The government is not relaxing the export regs because they want to; instead, the Executive Branch of the government is relaxing the export regs because the Judicial Branch has told them, in essence, "if you don't relax these regulations, we will relax them for you".
Remember that the Government has three branches, and each branch thinks the government would work much better if the other two branches would just shut up and do as they're told. The Executive Branch often fights the Judicial and Legislative branches, the Judicial fights the Executive and Legislative, etc.
</INFERENCE>
Also, if PGP is effective, what key length is necessary to really be secure?
1,024 bits is probably secure for everyday use. I use a 2,048-bit key.
There's not much point in going beyond 2,048 bits. Really. PGP (particularly the unauthorized ckt builds) will let you exceed 2,048 bits, but there's not much point in it.
Re:Encryption is not the answer.
on
Inside Echelon
·
· Score: 2
Hotmail is laughably insecure; I believe it was Hushmail to which you meant to refer.
First, I'm a fan of Hushmail. I think they do a moderately good job (as opposed to some of the clowns in the field), and Genevieve is a sweetheart. That's well and good for them, but the problems with browser-based secure email are still substantial.
1. No code review. Hushmail's code is available for review, but as of this writing it hasn't been security-audited by a respected infosec house. There is no security without a security audit. [*]
2. Susceptability to Trojans. Okay, so they have a certificate from an appropriate CA... how many people actually check the certificate for authenticity?
3. Complexity. Believe it or not, a lot of people can't understand that "if you send email from a Hushmail account to another Hushmail account, it's delivered securely; otherwise, you take your chances". I've had people send sensitive information to my Hushmail account (here) from a Hotmail account, believing that the Hushmail address was some magic pixie dust that made everything secure.
4. Distinguishability. There are certain "secure" email services which get laughed at, lots, by people in the security field. There are other services which get careful and qualified respect. By and large, the userbase is oblivious to this; they make their decisions based on marketing. There are some services I've seen advertised in national news magazines which make themselves out to be superhumanly secure--and then, in the fine print, mention that "oh, by the by, we escrow your keys just in case". It is extremely difficult for an average consumer to make an even mildly informed decision as to which services to patronize.
... None of these problems are Hushmail-specific; they plague all of the browser-based email providers, some moreso than others. While I wholeheartedly agree that browser-based email services can provide a simpler, more secure way to send mail, they're just an evolutionary step towards where we need to go--they aren't a panacea.
[*] Unfortunately, the reverse isn't true--just because a product has passed a security audit doesn't mean it's secure.
Encryption is not the answer.
on
Inside Echelon
·
· Score: 3
For every social problem, there is a technological solution that is elegant, simple and wrong. The current state of encryption technology is a brilliant example.
Lots of people have done studies of how easy it is to properly use encryption software. In one study, something like half the test subjects were unable to send out a PGP-encrypted message--this wasn't using the (arcane) command line of the 2.6 versions, but the much slicker GUI of the 5.x versions.
Guess what? It hasn't gotten much better. In some respects, it's become worse. The vast majority of people are unaware of the scope of automated surveillance, and as such, they don't care. Of the minority that is aware, the majority of them are unaware of how useful encryption tools can be. Of the minority that is aware, the majority are unable to look at competing products and come to an informed determination about which product is the superior of the two--"Honey, this one says it uses `superhumanly strong 40-bit Blowfish email encryption', and the other one just says it uses Triple DES, which do you think I should buy?".
Of the minority which IS aware of the scope of the problem, which is ALSO aware of the existence of tools, which is ALSO capable of selecting the proper tools and using them properly...
... most of them find encryption to be too much of an inconvenience.
Passphrases are hard to remember; at 1.2 bits of entropy per character (roughly), you need about 120 characters for a good passphrase. That's about two lines of text from a novel. Assuming you can type 60 WPM, or five characters a second, you're going to be spending 24 seconds just entering your passphrase.
That's inconvenient. How do most people deal with the inconvenience? They simply choose not to bother, or else they choose trivially weak passphrases, or they cache their passphrases for an absurdly long time, or...
Encryption, by itself, is not the answer--not unless you're so rabidly paranoid that you're willing to put up with the inconvenience even for something as simple as an email to your girlfriend saying "hey, I'm going to be home early from the office tonight, want to catch a movie?".
Some people are. I'm not. I use encryption for the things which are important--truly confidential material; company secrets, or communications with my lawyer, or other things in that vein. But otherwise, it's just damned inconvenient.
What we need is not "more encryption, dammit!". What we need is more usable encryption. This means:
* Encryption which is EASY TO USE * Encryption which is HARD TO SCREW UP * Encryption which is CONVENIENT * Encryption which is TRANSPARENT TO THE END USER
We don't have any of that right now. We're not even close on most of those counts.
-- And by the by, there's absolutely no point in an average person using a 4,096-bit key.:) Right now even a 1,024-bit key is pretty safe, and a 2,048-bit key ought to be just fine for the indefinite future.
Everyone here who's been advising you to use steganography is well-intentioned, but missing the point. If the secret police suspect your target of receiving subversive information, then they'll likely look for steganography.
It's not hard to flip the low-order bit in an image file. In fact, it's trivial. They'll be expecting that and they'll intercept it. Don't try it.
Encryption is also not the answer. In Iraq and Syria, for instance, using encryption is a capital offense. Sure, your communications with your friend might remain secure, but your friend would be executed--whoops!
Another naieve way to handle things is to encrypt your steganography. "It'll look like random noise!", they claim. Well, yes... and that's exactly what it must not look like. You'd have to find some bizarre cipher with outputs specifically tailored to match the statistical patterns of image files. I don't know of any which can do this.
One possibility--and I am not reccommending this without a heck of a lot more peer review--is to start an email dialogue about esoteric mathematics. Include a big ol' table of random numbers and do some real mathematical analysis of it. If the email gets intercepted, the secret police will check the table for randomness (it's random, all right--passes every test!), they'll check your email to see if it's sensible (yep--you're doing actual mathematical research!), etc.
Of course, your friend knows that it's a one-time pad. (Not really a one-time pad--if you and your friend both have a cipher, a shared key and a shared IV, you can run the cipher in OFB mode to generate a lot of statistically random data. You generate the random data, then use it as a one-time pad for your message; your friend re-generates the one-time pad on his/her end, then reverses the one-time pad. Strictly speaking, this is just OFB encryption, not a OTP.)
Of course, the secret police will know that it's an encrypted message... but they won't be able to prove it. Whether or not that stops them depends on just how totalitarian the state is. Some states will just shoot you in the back of the head and get it over with. Others, such as China, must at least make an attempt at a fair trial in order to soothe Western critics.
Worse, you're the sort of idiot who, instead of having any facts to back up outrageous allegations, says "if you only knew what I know, then you'd agree with me".
Speaking as a communications security hardcase, and also as someone who has worked in a DoD-funded research lab, and also as someone who secured data in that lab using PGP...
... what the hell are you talking about?
Really?
Nothing happened to me for using PGP to secure a couple of files. In fact, I don't think anyone even noticed. Security in those places isn't as tight as you're making it out to be.
Answer the question, please. Do the power analysis--it would take an optimal computer about one year at a constant 250 megawatts of power to break a 128-bit cipher.
If the NSA is so advanced that it has perfect computers running at a cryogenically-cool 3.2 Kelvins and hooked up to its own nuclear power plant just to flip the bits, I'd really like to know about it.
I'm not being facetious here. If you have any hard facts to back up your assertion, I'd like to hear them.
Disclaimer: I am not, in any way, speaking for my company. More than that, I don't have my reference books handy, so I'm going purely from memory--I may be off on a detail or two.
PGP (more accurately, programs which implement the OpenPGP specification) is not insecure when properly used. By "properly used" I mean choosing a reasonable size for asymmetric keys, choosing a reasonably good passphrase, and practicing good email discipline--unrevealing subject headers, not sending anything cleartext which could compromise your key, etc.
Is it trivial to use PGP/GPG properly? No, and that's the biggest problem with PGP/GPG. Still, that's not what Jon Katz's source said; the strong implication was that government agencies could, either by brute force or cryptanalysis, break a PGP-encrypted email in a day. So let's address that now.
In order to break a PGP/GPG encrypted email, either the asymmetric or symmetric components of its cryptography need to be broken. Breaking the asymmetric component requires either an efficient way to factor large numbers[*] (for RSA) or an efficient way to solve the discrete logarithm problem[**] (for El Gamal).
After more than twenty years of study, such efficient algorithms remain Holy Grails of cryptographic research.
Breaking the symmetric component requires some efficient way to break the cipher. By "efficient" I mean better than brute force, better by several orders of magnitude. Being ragingly paranoid here, I'd expect government agencies (DGSE, NSA, etc.) to be able to break 80 bit ciphers by brute force. The weakest [+] cipher in the OpenPGP spec is Triple DES at 112 bits. That still exceeds governmental capabilities by a factor of four billion or so.
Basically, the claim that "the NSA can break PGP-encrypted email in a day" is so much hogwash.
That being said, there are undoubtedly attacks which government agencies can perform against ciphers. Cryptanalysis is just very rarely one of them. It's far cheaper for the government to Van Eck your monitor, or break into your apartment and plant eavesdropping devices, or crack your box to grab your private key and plant a keypress sniffer to take your passphrase. And if you're sending stuff which is so tempting to the government that they'd go to this effort, then you probably want to invest in something more than PGP/GPG.
There are many attacks which exist against PGP/GPG. It's just that, to the best of my knowledge, there are no good cryptanalytic attacks against PGP/GPG.
[*] Strictly speaking, this isn't true--we don't know for a fact that you have to come up with an efficient factoring algorithm to break RSA. It seems to be strongly implied, but there has never been a formal proof of this requirement.
[**] This isn't true, either--see the above footnote. Interestingly, coming up with an efficient factoring algorithm doesn't help you solve discrete logarithms, but an efficient solution to the DLP will give you an efficient factoring algorithm.
[+] 3DES is "weakest" in the sense that it has only a 112-bit keyspace, as opposed to the 128-bit keyspaces of the other ciphers used by PGP/GPG. There are some extremely esoteric attacks against 3DES which bring down its complexity somewhat, but it's still solid as a rock. 3DES has survived a quarter-century of cryptanalysis and nobody's been able to hit a home run against it yet; this means that 3DES, while "weakest" in the sense of keyspace, is probably the strongest cipher in common use today.
IANAL, but my father is a judge, my cousin is a DA, another is an ex-cop, another is... well, you get the idea. My experience is practical, not professional, and I am not suggesting that this is in any way a substitute for real legal advice. That being said:
1. YOU CAN BE SUED FOR ANYTHING.
There are laws on the books which are meant to cut down or eliminate frivolous lawsuits, but judges rarely reprimand attorneys for wasting the court's time.
2. LAW REALLY DOESN'T MEAN ALL THAT MUCH.
As soon as the jury is seated, it's an entirely different ballgame. Juries occasionally follow the law with diligence and probity, and occasionally they completely buck the judge's counsel and do whateverthehelltheydamnwellplease.
In this instance, a jury wasn't seated--the reason why I bring it up is because many legal proceedings do involve juries, and most/.ers seem unaware of just how mercurial juries can be.
3. TEMPORARY INJUNCTIONS ARE JUST THAT.
Temporary, and injunctions. Judges are prickly people, as a rule. Most of them are control freaks of such a high order as to dwarf absolutely any other profession out there--including doctors. There are two things which judges universally fear, though: one is being overturned on appeal, and the other is being humiliated.
If someone comes before a judge and says "Your Honor, this bad person over here is doing something which will cause substantial and irreparable harm unless you do something to help me right now", the judge has three choices:
* He can schedule a full hearing, and tell the aggrieved party "well, let's wait two or three months and just handle a full, permanent injunction hearing"
* He can execute summary judgment and declare that no such irreparable harm exists, and refuse to do anything
* He can issue a temporary injunction, and schedule a permanent injunction hearing for later.
... Remember: judges hate to be overturned on appeal and they hate to be humiliated. If the judge chooses the first or second option, that leaves him (a) free to be overturned, and (b) if the judge is wrong and irreparable harm does occur because the judge didn't issue an injunction, the judge will be publically humiliated.
Judges, therefore, overwhelmingly tend to be very lenient with temporary injunctions. Many of them claim that this leniency is in everyone's best interests, and it may well be--but I'm a cynic, and this colors my analysis.:)
4. TEMPORARY INJUNCTIONS ALWAYS EXPIRE.
This one is simple. Temporary injunctions always expire, and permanent injunctions last for as long as the Court (not the parties involved--at least, not necessarily) wants them to. In order to move from a temporary injunction to a permanent injunction, well--let's skip the procedural details, because it's likely not interesting to/. readers. Instead, just remember what I said about judges; they hate being overturned, and they hate being humiliated.
This gives them extremely strong motivation to consider permanent injunctions very carefully. If they misstep on procedural or logical grounds, it's cause for overturn on appeal; and if they make the wrong decision and someone loses their shirt as a result, then the judge gets humiliated.
So judges tend to view permanent injunctions with a much more careful, and skeptical, eye than they do with temporary injunctions.
... But, as I said, I'm not a lawyer and I don't know beans about the legal system. You'd be a fool to think that this is anywhere near competent legal advice.:)
C# permits pointers (and everything associated with them) and the disabling of garbage collection. Neither of these can be duplicated in Java. It might be able to implement a subset of C# which would be more Java-friendly, but not the full set of C#.
Is the wireless Web secure? No. Is the Web secure? Also no. There is no difference, realistically, between wireless and wired networks. Have you ever used a satellite link to send data across the globe? A lot of people have and never realize it. The Net is a hybrid network; wired and wireless coexist equally. They only exist to transport data, and data sent in the clear is just as vulnerable on a wire as it is via wireless as it is via smoke signal.
Remember that a network is only as secure as its weakest node. Unless you take significant precautions, your Web transactions are insecure, period. Even HTTPS isn't a great solution.
(I am an InfoSec professional IRL, but this is absolutely not professional advice. Nor am I speaking for my company.)
Who says you'd even have to go to the trouble of actually encrypting it. Well encrypted data should be indistiguishable from randomness.
Not quite. Look at a PGP message, for instance. Most people would probably agree that, properly used, PGP provides good encryption--but it also has a very recognizable message format. There's an entity which specifies the algorithm to use (IDEA, 3DES, CAST128, etc.), an entity which is the sender's public key, an entity which is... etc., and so on. If the PGP message format was not precisely defined and recognizable, it would be vastly more difficult to use PGP. ("Damn! Err, okay, so what algorithm did they use to encrypt this, anyway?")
If all you want to do is run data through a cryptographic algorithm, then yes, it will come back out as something which should pass every statistical test for randomness.
Running data through a cryptographic system, what comes back out should be easily recognizable as the output of that specific system (unless, of course, the system was specifically designed to be indistinguishable from random noise).
Very few people use cryptographic algorithms by themselves. Most of the time, when people say "I encrypted it with Blowfish", they mean "I encrypted it using a cryptosystem which used Blowfish for its cryptographic core".
I am an InfoSec professional, but this is not professional advice. (Gads, I hate lawsuit-happy cultures like ours...)
Bruce Schneier's YARROW is the only PRNG I'm aware of which has actually gone through formal cryptanalysis. I'm not overly fond of YARROW--it's extremely slow with its 3DES/SHA-1 core--but the fact that it's been cryptanalyzed makes it much more trusted than almost any other PRNG.
Substituting a fast cipher like Blowfish or an AES candidate, and replacing the hash algo with MD5 or somesuch, would result in a much faster YARROW. Unfortunately, this also invalidates the cryptanalysis, since the modified version wouldn't have undergone the same level of cryptanalysis: still, if I remember correctly, YARROW is intended to be both hash- and cipher-agnostic.
IRL, I'm a full-time PGP hacker for PGP (part of Network Associates)--so keep in mind that my perspective may be biased by my employment. (And as always, I am not speaking for my employer, and this post does not constitute professional advice.)
Basically, it proved vulnerable to some esoteric attacks. It's no longer as strong as was once thought; while it's still secure, 4.5 rounds have been broken (last I heard--considering how quickly the field moves, it might be more now.)
Between its small security margin, its rather slow operation speed and the obnoxious patent (obnoxious both in terms of cost, and in terms of how difficult Ascom-Tech A.G.--and now apparently Entrust, too--made it to obtain one), people have just decided to use other ciphers.
IDEA's big selling point for the longest time was that it was the only trusted replacement for DES (barring 3DES, of course). Since we now have literally dozens of trusted replacements for DES, why bother with IDEA? Blowfish is well-trusted and pretty snappy in its operation; I'm not as fond of CAST as others are, but it's held up rather well (well enough to have been a strong AES contender).
When we have ciphers which are faster, less patent-encumbered and offer a larger security margin than IDEA, why should we continue to use IDEA?:)
I am an InfoSec professional IRL, but I am not speaking for my employer, yadda yadda, this is not professional advice, insert standard disclaimer.
First: I've never heard of this fellow. I don't recall seeing his name in any of the crypto journals. I don't recall seeing any particularly clever attacks from him in the past. Protocol design is tough; it is an exceedingly nontrivial task, even harder than designing new algorithms. Anyone who says they have a great new protocol is most likely lying, unless they're a Tuchmann, a Coppersmith or a Schneier.
Always assume all new protocols are full of it, until enough time and attacks have gone by to give confidence that the protocol is only mostly full of it.
Second: this system is not secure. Repeat after me: a one-time pad is secure as long as it's only used once. The likelihood of a birthday attack is orders of magnitude more likely than he's making it out to be. The reason for this is because Net traffic is not uniform; certain places tend to be "hot" and others "cold".
Let's have a thought experiment. Let's say Slashdot begins to implement this system, and has a few thousand "pad blocks" available. This means a few hundred megabytes of purely random data--let's completely ignore the practical difficulties of purely random data for now and just assume we can do it.
When Alice decides to store something unpopular and encrypts it with Pad(s) alpha, beta and gamma, so that Bob and Charlie can read it later, what's Alice going to do? -- Probably use one of the first twenty pads listed. Why? Because people are lousy at choosing random numbers. If you ask someone to pick a number at random, they're most likely to pick a number between one and ten, not one and fifty billion. Things that are at the head of a list get selected more often than those that aren't.
Let's say that Slashdot randomizes these pads, though, so they always come up in an unpredictable order. (Never mind the practical difficulties in how to do this in the first place. It's a thought experiment. Just keep alive in the back of your mind the fact that (a) we've had to create hundreds of megabytes of purely random numbers, and (b) we have to present them to people in a purely random way.)
After some mathematics, Alice's super-secret Neiman-Marcus cookie recipe is now pretty much totally obscured. She posts the recipe to a Website, and then tells Bob and Charlie, "Psst! I posted the information to this site. Find pads with IDs of [she recites their IDs] and use that to recover the information!"
At that point the secret police storm in, having been eavesdropping on the entire conversation. They throw Alice, Bob and Charlie in jail. They go to the website, pull the information, get the pads and read the Neiman-Marcus Cookie Recipe for themselves. Guess what? This protocol has completely, totally and utterly failed.
The naieve response is to say "well, they wouldn't say it in the open... they'd use encrypted email to share the pad IDs!" Okay, fine. All that's happened is the encrypted email is the weak link in the security; if that goes, the entire scheme falls apart.
Now recall those two extremely thorny problems from before. Hundreds of megabytes of purely random data are very hard to come by, and purely random presentation of random data is very hard to do. Add in the implementation weaknesses to the weakness of the communications channel between Alice, Bob and Charlie, and you've got a protocol which has very little merit.
This protocol solves a problem which doesn't exist, as far as I can tell. Now, admittedly, I'm not the sharpest knife in the drawer and I'm also bone tired and I could be totally misunderstanding what the goal of the protocol is.
But for a secret-sharing protocol, or as a way to securely store information in a way which is deniable, it's pretty dismal.
I'm an InfoSec consultant IRL, but this is not professional advice. (And soon I'll be a full-time paid PGP hacker. Yay. )
There are literally dozens of perfectly good ciphers out there. Blowfish, 3DES, Twofish, IDEA, RC2, RC4, SEAL... the list goes on and on and on.
No two ciphers are exactly identical. Cipher selection is based on these minute tradeoffs between ciphers. For instance, 3DES is solid as a rock but is quite slow. I wouldn't use 3DES to encrypt a high-bandwidth realtime communications link, obviously, although I would readily use it to encrypt a 100k file on a disk.
Blowfish is very fast, but key setup is slow--so I wouldn't use it in an environment where keys would be changed frequently.
IDEA is strong and fast, and is well-suited in a whole range of endeavors. It's also encumbered by patent, though, and some of my clients don't want to shell out money to Ascom-Tech A.G..
... In the final analysis, cipher selection is dictated more by secondary factors than by cipher security. There are so many strong ciphers out there that we can engage in personal preference and pay attention to "other details", like performance. It's pretty simple stuff, really. I have a harder time selecting a mode for a cipher than I do selecting a cipher.:)
My own personal fave cipher is GOST, mainly because you get retro-cool points for using it.:) I wouldn't use it in a production system, but when it comes to noodling around with novel crypto (to quote Enoch Root), GOST is my favorite.
I am an InfoSec professional IRL; however, I'm not a college prof and I've never taught a class beginning to end.
1. COVER FAILED PROTOCOLS.
The field is littered with broken protocols and algorithms. Some of them are broken because they're stupid (so study why so many people thought they were smart). Some are broken because they got overtaken by technology (so cover how the protocol left itself vulnerable to technology [1]). Some are broken because the assumptions underlying the protocol are incorrect [2]. Some are... etc. Study the failed ones closely, and learn why so many people thought for so long that they were good.
2. STUDY PRACTICAL AND THEORETICAL DIFFERENCES.
IPsec is a very good protocol in theory; in practice, it's painfully mediocre. IPsec works well as a lesson for how "the best-laid plans of mice and men gang aft agley"; somewhere inside of it there's a beautiful, small protocol screaming to get out, but it gets bogged down in elephantine bulk.
Theoreticians tend to create complex protocols which are damnably difficult to implement well (but when they are, they tend to be nice). Those who take a more practical approach create simple algorithms which can be implemented well, but don't address subtleties.
For examples, see [3] and [4].
3. STUDY THE MISTAKES PEOPLE KEEP ON MAKING.
There are very few really new protocols; people just keep on re-inventing old ones. They also make the same mistakes over and over again. We've known ever since WW2 that poor passwords lead to compromised ciphers. We've known that re-using one-time pads make it trivial to cryptanalyze data. Yet, certain nameless day-trading firms limit user passwords to six alphanumerics, case-insensitive--that's a weak password. Yet, we sometimes see KAK ciphers (OFB ciphers) being used with a repeated IV--that's the same as repeating a one-time pad.
Programming errors are even more common than protocol errors, and can be just as damning [5].
[1] DSA, for instance, originally used a 512-bit modulus. This was way too short for long-term security, and they had to revise it to 1,024 bits almost immediately. It is likely that in the not-too-distant-future, DSA will have to be changed yet again.
[2] Atjai-Dwork and Cramer-Shoup are good examples here.
[3] Kerberos is an example of a theoretically sound protocol which is difficult to implement well in practice. Check the modifications which have been done to Kerberos--for instance, why PCBC mode was used for crypto and why it was changed to CBC mode.
[4] Schneier has some good examples of digital-cash and digital-voting schemes which are practical, but fail to address subtleties.
I am an InfoSec professional IRL, but this is not professional advice.
==========
Ref: point 2, "Remember when 128 bit keys was way too big to be factored? I do, and I'm all of 28 years old."
128 bit keys were never considered too large to be factored. Various people were positing RSA-129 as being secure back in the '70s, but that was 129 *decimal digits*, not *binary digits*. (I may be off on the exact 129 figure--it was about that, though.)
To brute-force a 128-bit number requires you check every prime through 2^64. This is not very difficult. Using an intelligent factorization algorithm will make factoring a 128-bit number trivial.
To give a rough comparison, 2^20 is approximately equal to 10^6. 2^20 raised to the sixth power is 2^120, add on another factor of 2^8 (which is approximately 10^2)... you're looking at 10^6 raised to the sixth (10^36) with another factor of 10^2, for a grand total of 10^38.
Factoring a 38-digit number is not very hard. Factoring a few *hundred* digit number is nontrivial.:)
I am an InfoSec consultant IRL; and in the course of my job, I've occasionally stumbled across some interesting tidbits (which credit-card companies use repeated-XOR encryption, which HMOs keep medical information secure with DES, etc). I have heard reports, but have not been able to verify their accuracy, that at one time Russia's Strategic Rocket Forces were using 3DES (with three independent keys) to secure their nuclear-launch codes.
If true, that suggests a very high degree of confidence in 3DES.
I've got to say that 3DES isn't my favorite algorithm, but properly implemented, it's an extremely secure algorithm. Unfortunately, many software DES implementations manage to screw up the DES spec (probably, I think, due to the infernal complexity of DES).
Slashdot Mirror
My father used to counsel me that if you've got to spend more than thirty seconds explaining why what you're doing is right... it's probably not. It's been a surprisingly good rule for me, as long as I remember that it's a general rule and not an absolutist statement.
With that said, the important thing is just to boil it down to the simplest accurate moral principle you can find. If I were in your situation, I'd say "A guy is being ripped off by people I'm working for."
Your choices, as near as I can tell, are pretty minimal.
You can do nothing, which most people would do--but the place in Hell closest to the fire is reserved for the people who do nothing.
You can tell the author, in which case you'll have a lot of shit raining down on your head if you're ever found out. The author will have verification from inside the company that his copyright is being flagrantly disrespected, and the author will have the choice of pursuing further action.
Or you can quit. While it might seem noble to fall on your sword, this amounts to "doing nothing". Management won't change their behavior because you quit, or threaten to quit; once you quit, you're out of a job, the original author is still in the dark about the copyright violation and the company gets to keep on doing the unethical thing.
There are other options available to you, but the above three seem to be what all of your options boil down to. Given the above options, I'd inform the author--discreetly and carefully. If I got discovered, I'd voluntarily resign.
I've posted this before, in a different form. But since people keep on making the same boneheaded statement again and again, I have to keep on presenting myself as an Average Joe exception to the rule.
First, I'm not Joe Schmoe from Asshole, Indiana. I'm from a small town in Iowa, which is probably even more podunk than Asshole, Indiana is. And I'm fairly certain I've been under surveillance at least once in my life, and maybe far more often than that.
Back in 1993 I was just getting interested in crypto, and I had an email exchange with a notorious arms dealer who was under investigation by the U.S. Government for arms smuggling. His name was Phil Zimmerman, the guy who wrote PGP. It was an innocuous email conversation talking about large number theory. But realistically, Phil was under investigation for arms smuggling (specifically, violation of ITAR/EAR), so it seems pretty reasonable for me to believe that he was under some kind of surveillance.
Guess what? Since I was talking to him, that meant I was under surveillance, too.
How many of us here have friends who are active in the phreak community? Go on, raise your hands. How many of you believe that your friends are so 1337 that they'll never be caught, never be fingered to the cops by their friends? Wow. So you have 1337 phreak acquaintances or friends, and you think that they might come under police investigation someday?
Well, guess what, buddy. If they come under investigation... so do you.
Loyd Blankenship, from Steve Jackson Games, found this out the hard way. Remember the Secret Service raid on SJG? That was predicated, in large part, on Blankenship's association with people the government declared to be naughty. It was a pretty tenuous freakin' association, too--and the Secret Service still decided to swoop down and raid the place.
In my last job, I was doing InfoSec for a San Francisco start-up which was going to be expanding into Europe. This concerned me, because a lot of European businesses are partially owned by the government, and the European intelligence agencies (particularly France's DGSE) have been known to eavesdrop on communications for purposes of economic espionage. The NSA does the same thing for American firms--but the NSA claims that it only does so to counteract foreign governmental abuses of their intelligence apparata.
Was I concerned about the DGSE? Hell yes. Little ol' me, the hayseed who grew up on an Iowa farm, was working in an industry where governments commit economic espionage.
A few months ago I became tangentially involved in a criminal investigation. Although I wasn't the target of the criminal investigation, I worked closely with the individual who was under the FBI's spotlight. Guess what? That spotlight got pointed against me, too. Not for long, just long enough for the FBI to realize that I had nothing to do with it. But I didn't like it one bit.
We don't have to be important or criminals to come under the spotlight of government scrutiny. We don't have to be doing anything wrong. We can be community leaders, outstanding citizens and decent human beings--and still, if you associate, knowingly or unknowingly, with people which the government is taking an interest in... well, you can expect to get hit.
Period.
First, I'm a certified, certifiable cryptogeek, so I'm probably biased here. That being said:
:)
:)
Crypto.
The first rule for teaching (or maybe the second, right after "No matter how much they're the spawn of Lucifer, love the kid anyway") is that you don't have to teach a subject; if you can make the subject something the kid wants to learn, the kid will tear into it with the kind of unholy abandon that only teenagers can muster.
Think about the virtues of crypto, and how you can make your students enjoy it. Make it a point to teach the real stuff, not something watered-down. Emphasize that this is "military-grade" stuff [*], and that nobody--not the NSA, not the CIA, not anyone--can break these ciphers [**].
Tell the kids this, and they'll figure out pretty quickly that there are a lot of things they can do with crypto. Some of them will undoubtedly give your principal gray hair, but hey, that's the price of education. Not as if some of those Satanspawn don't already give him more salt than pepper.
There are a lot of ciphers which are fairly simple to sketch out on the whiteboard. I'd suggest Blowfish or RC4; both of them are exquisitely simple in theory, and straightforward in practice. There exists a lot of source code for Blowfish, at least a dozen different implementations in the public domain or Free Software, and RC4 (also sometimes called "arcfour") is almost as widespread.
You'll wind up teaching them about number theory, groups/sets, Boolean logic, the whole nine yards. You could easily spend most of a quarter writing this, and each day in class you'd cover a different aspect of computer science, along with a surprising amount of mathematics.
Crypto is a surprisingly comprehensive discipline. Good crypto libraries require that the programmer have a master-level knowledge of software engineering principles, advanced knowledge of their programming language, and sophistication in how they think about problems.
And when the kids start sending each other PGP-encrypted email over the school network, plotting the violent overthrow of the school and how to best string up their most-hated teachers from trees, you can sit there with a beatific, immensely satisfied smile and say--"Those are my kids."
If you want to know more about crypto and the classroom, feel free to drop me an email. I've got a C++ library for Blowfish which I wrote to teach some younger friends good software engineering principles--it's well-designed, with a boatload of documentation.
[*] Gloss over the fact that there is no accepted definition for "military grade".
[**] Gloss over the fact that there are easier ways to attack ciphers than by cryptanalysis.
How much does a private college cost nowadays? The one I graduated from is running around $25,000/yr nowadays. Nonprofit or not, that's a lot of money. It's so expensive, in fact, that the vast majority of students have to get financial aid just to attend school; again using my alma mater as an example, $8,000 a year of my tuition went to subsidize other people's educations. (I was, regrettably, a full-pay student. After graduation the alumni office got in touch with me asking me if I'd be willing to make a donation to the scholarship fund, and I got a little bit irate with them--after all, I donated $32,000 to the scholarship fund over four years and I didn't even get a thank-you note.)
If there aren't enough full-pay students, then there have to be cutbacks in the amount of financial aid the college gives; and if that gets cut back, the college winds up serving fewer and fewer students. And since the cost of running the college is amortized over the entire student body, if the student body shrinks, rates go up--sometimes dramatically.
When I applied at my alma mater, it was considered to be a very selective school. The average ACT score was a 28 or so, and SATs were similarly high. Over the last several years, financial pressures have forced the college to lower its admission requirements until it is no longer a selective college--basically, "if you graduate from high school and you're a full-pay, we will walk into Hell itself if that's what it takes to get you in the door".
Has the academic mission been corrupted by money, and the financial crunch which all educational instututions find themselves in? Damn straight. Is it anybody's fault? Not really, no. It's just one of the big rules of life. Money changes everything; if you have money, you have a lot more options than if you don't have money.
If corporations want to offer education, will the education they offer be affected by their profit motive? Yep. Just like the students they accept will be dictated by their target markets.
But where Metroworks U. might be affected by "if they aren't buying $500 a year of Metroworks products, kick 'em out, and if their OS is a platform which we don't support, don't accept 'em", private colleges say "if they aren't filling our coffers with $X, decline to invite them back for another year."
Nonprofit institutions have to worry about the bottom line, just like everyone else.
Do the power analysis. It requires a minimum of kT energy to flip a bit, where k is Boltzmann's constant (1.38 * 10^-23 joules per Kelvin) and T is the temperature your computer is running at (the background temp of the universe is about 3.2 K).
It would require an optimal computer [*] about 250 megawatts of power [**] and a full year of time to break a 128-bit cipher.
[*] We don't have anything close to this.
[**] 250 Mw is a hell of a lot of power. Don't ask me how you'd keep your computer from melting down from the heat. Or how you'd keep it at 3.2 K, for that matter.
128-bit ciphers are secure for the indefinite future. I don't expect anything short of enormous advances in quantum computation to make a dent in them.
The following is not professional advice. I have not done an audit of Hushmail; I've looked at their code a little bit, along with how they handle messages and encryption.
My impression is that there are some flaws in the design--lack of a security audit, lack of choice in ciphers, possibility of Trojaning, dependence on your browser handling HTTPS properly, etc.--but all in all, Hushmail (click here) seems to be the best option out there right now for secure Web-based email.
I've used Hushmail in the past for email communications with my attorney (she's too tech-naieve to use PGP properly, but she understands "if I send him email at his Hushmail account from my Hushmail account, then I'm doing my part to keep attorney-client privilege secure").
I've got to say that I feel safer with PGP/GPG, but Hushmail is a hell of a lot better than most of the snake-oil that's sold out there.
I'm not saying Hushmail is good; I can't say that, given that I haven't done any hardcore analysis of it. I'm only saying that, based on my experience with it and based on what I've reviewed of their setup and policies, Hushmail seems to be the most clued-in of all the current secure Webmails.
Speak for yourself.
During the years when export of cryptography was illegal, I was habitually encrypting everything crypto-related which I sent to other people via email. After all, the government went after Phil Zimmerman, and once tried to tell a group of mathematicians that they couldn't deliver a presentation on RSA. The government was very interested in export-control, and using crypto on email conversations about crypto was just a prudent way to keep myself safe and lawsuit-free.
Let's also not forget the business world. My previous job was for an Internet start-up which was going to be expanding quickly to Europe and the Pacific Rim. Certain countries (France among them) have industries which are partially or wholly owned by the government; and the governments of certain countries (France among them) have histories of using their intelligence agencies to gather economic intelligence on the competitors of these government-owned industries.
Were we concerned about the DGSE eavesdropping on our plans to set up shop in Europe? Damn straight.
And let's not forget the fact that you don't have to be important to warrant being searched. Let's say that you're a journalist and you're a big nobody. The government doesn't care about you. You're talking via email with someone, using them as a reference for a story, or maybe they're providing you with leaks, or whatever.
Let's say your source is also under investigation for drug smuggling. The FBI can eavesdrop his emails, but that might tip him off. Instead, it's easier to eavesdrop on the emails of the people he talks to.
After all, drug smugglers tend to take extreme precautions with their communications. There's no guarantee that the people they talk to do. It just makes sense.
... I qualify on all three points listed above, you see. I was violating ITAR/EAR before it became fashionable, and I was very concerned about getting a call from the FBI.
I worked for an industry in which we had very real concerns about foreign governments eavesdropping on our electronic communications and giving our secrets to competitors.
And I talk with a few lawyers and a journalist, and in 1993 I had a pretty long set of email conversations with Phil Zimmerman. I know that at least one of those people was under government surveillance at the time, and I don't know about the others.
So your statement--"I don't think anyone reading Slashdot is important enough that the government would want to read through his or her e-mail"--is quite false.
Also keep in mind--in every one of these events, what I was doing was legal. ITAR/EAR was struck down as unconstitutional in its control over computer source code; my business was totally legal; my communications with lawyers, PRZ and the occasional journo are all completely, totally legal.
Just because you're one hundred percent legal doesn't mean the government isn't going to snoop.
How effective is encryption?
Depends on what you're trying to do with it. It's just a tool, nothing more. A hammer is pretty useless when what you need is a screwdriver; same thing with encryption.
If you're sending a love letter to your sweetheart and you want to make sure that it won't get intercepted in transit, encrypting your email is very effective. If you're sending details about your Hizbollah contacts and how you're building a nuclear weapon for them, you probably want more tools than just encryption.
Are we sure they can't break it?
No. Hell, we're not even sure we can't break it. Much of cryptography is built on math problems which are conjectured to be insanely, mind-bogglingly difficult. These math problems have never been formally proven to be as difficult as we think they are, though. Some people think that simple, elegant solutions exist to these problems exist, but so far they're in the minority.
This is not a death-knell for cryptography, though. So far, we're pretty certain that we can't break it by conventional means, and we've got reason to be optimistic that governments can't break it by conventional means, either.
Of course, the government has decades of experience at unconventional means--planting eavesdropping devices, shadowing people, bugging their phone lines, bribing people to give up their encryption keys. Encryption can't really help very much against these unconventional methods.
Now that the USA seems to be relaxing its control over exportable crypto, can we take this to mean that they know they can defeat it?
Absolutely not. Anyone who tells you otherwise is a fool. We do not know what inferences we should draw from the Government's relaxation of crypto regs. What we do know is the following:
1. Federal courts have decided, at the appellate level (one step below the Supreme Court), that source code can be Constitutionally protected free speech.
2. Federal courts have decided, again at the appellate level, that cryptographic documents (whether published conventionally or on the Web) are Constitutionally protected free speech.
The inference that I draw from those two events is...
<INFERENCE>
After losing those two almost back to back, the Government didn't have much choice but to relax the export regs--because the Federal courts had declared the export regs to be unconstitutional!
The government is not relaxing the export regs because they want to; instead, the Executive Branch of the government is relaxing the export regs because the Judicial Branch has told them, in essence, "if you don't relax these regulations, we will relax them for you".
Remember that the Government has three branches, and each branch thinks the government would work much better if the other two branches would just shut up and do as they're told. The Executive Branch often fights the Judicial and Legislative branches, the Judicial fights the Executive and Legislative, etc.
</INFERENCE>
Also, if PGP is effective, what key length is necessary to really be secure?
1,024 bits is probably secure for everyday use. I use a 2,048-bit key.
There's not much point in going beyond 2,048 bits. Really. PGP (particularly the unauthorized ckt builds) will let you exceed 2,048 bits, but there's not much point in it.
Hotmail is laughably insecure; I believe it was Hushmail to which you meant to refer.
First, I'm a fan of Hushmail. I think they do a moderately good job (as opposed to some of the clowns in the field), and Genevieve is a sweetheart. That's well and good for them, but the problems with browser-based secure email are still substantial.
1. No code review. Hushmail's code is available for review, but as of this writing it hasn't been security-audited by a respected infosec house. There is no security without a security audit. [*]
2. Susceptability to Trojans. Okay, so they have a certificate from an appropriate CA... how many people actually check the certificate for authenticity?
3. Complexity. Believe it or not, a lot of people can't understand that "if you send email from a Hushmail account to another Hushmail account, it's delivered securely; otherwise, you take your chances". I've had people send sensitive information to my Hushmail account (here) from a Hotmail account, believing that the Hushmail address was some magic pixie dust that made everything secure.
4. Distinguishability. There are certain "secure" email services which get laughed at, lots, by people in the security field. There are other services which get careful and qualified respect. By and large, the userbase is oblivious to this; they make their decisions based on marketing. There are some services I've seen advertised in national news magazines which make themselves out to be superhumanly secure--and then, in the fine print, mention that "oh, by the by, we escrow your keys just in case". It is extremely difficult for an average consumer to make an even mildly informed decision as to which services to patronize.
... None of these problems are Hushmail-specific; they plague all of the browser-based email providers, some moreso than others. While I wholeheartedly agree that browser-based email services can provide a simpler, more secure way to send mail, they're just an evolutionary step towards where we need to go--they aren't a panacea.
[*] Unfortunately, the reverse isn't true--just because a product has passed a security audit doesn't mean it's secure.
For every social problem, there is a technological solution that is elegant, simple and wrong. The current state of encryption technology is a brilliant example.
:) Right now even a 1,024-bit key is pretty safe, and a 2,048-bit key ought to be just fine for the indefinite future.
Lots of people have done studies of how easy it is to properly use encryption software. In one study, something like half the test subjects were unable to send out a PGP-encrypted message--this wasn't using the (arcane) command line of the 2.6 versions, but the much slicker GUI of the 5.x versions.
Guess what? It hasn't gotten much better. In some respects, it's become worse. The vast majority of people are unaware of the scope of automated surveillance, and as such, they don't care. Of the minority that is aware, the majority of them are unaware of how useful encryption tools can be. Of the minority that is aware, the majority are unable to look at competing products and come to an informed determination about which product is the superior of the two--"Honey, this one says it uses `superhumanly strong 40-bit Blowfish email encryption', and the other one just says it uses Triple DES, which do you think I should buy?".
Of the minority which IS aware of the scope of the problem, which is ALSO aware of the existence of tools, which is ALSO capable of selecting the proper tools and using them properly...
... most of them find encryption to be too much of an inconvenience.
Passphrases are hard to remember; at 1.2 bits of entropy per character (roughly), you need about 120 characters for a good passphrase. That's about two lines of text from a novel. Assuming you can type 60 WPM, or five characters a second, you're going to be spending 24 seconds just entering your passphrase.
That's inconvenient. How do most people deal with the inconvenience? They simply choose not to bother, or else they choose trivially weak passphrases, or they cache their passphrases for an absurdly long time, or...
Encryption, by itself, is not the answer--not unless you're so rabidly paranoid that you're willing to put up with the inconvenience even for something as simple as an email to your girlfriend saying "hey, I'm going to be home early from the office tonight, want to catch a movie?".
Some people are. I'm not. I use encryption for the things which are important--truly confidential material; company secrets, or communications with my lawyer, or other things in that vein. But otherwise, it's just damned inconvenient.
What we need is not "more encryption, dammit!". What we need is more usable encryption. This means:
* Encryption which is EASY TO USE
* Encryption which is HARD TO SCREW UP
* Encryption which is CONVENIENT
* Encryption which is TRANSPARENT TO THE END USER
We don't have any of that right now. We're not even close on most of those counts.
-- And by the by, there's absolutely no point in an average person using a 4,096-bit key.
Everyone here who's been advising you to use steganography is well-intentioned, but missing the point. If the secret police suspect your target of receiving subversive information, then they'll likely look for steganography.
It's not hard to flip the low-order bit in an image file. In fact, it's trivial. They'll be expecting that and they'll intercept it. Don't try it.
Encryption is also not the answer. In Iraq and Syria, for instance, using encryption is a capital offense. Sure, your communications with your friend might remain secure, but your friend would be executed--whoops!
Another naieve way to handle things is to encrypt your steganography. "It'll look like random noise!", they claim. Well, yes... and that's exactly what it must not look like. You'd have to find some bizarre cipher with outputs specifically tailored to match the statistical patterns of image files. I don't know of any which can do this.
One possibility--and I am not reccommending this without a heck of a lot more peer review--is to start an email dialogue about esoteric mathematics. Include a big ol' table of random numbers and do some real mathematical analysis of it. If the email gets intercepted, the secret police will check the table for randomness (it's random, all right--passes every test!), they'll check your email to see if it's sensible (yep--you're doing actual mathematical research!), etc.
Of course, your friend knows that it's a one-time pad. (Not really a one-time pad--if you and your friend both have a cipher, a shared key and a shared IV, you can run the cipher in OFB mode to generate a lot of statistically random data. You generate the random data, then use it as a one-time pad for your message; your friend re-generates the one-time pad on his/her end, then reverses the one-time pad. Strictly speaking, this is just OFB encryption, not a OTP.)
Of course, the secret police will know that it's an encrypted message... but they won't be able to prove it. Whether or not that stops them depends on just how totalitarian the state is. Some states will just shoot you in the back of the head and get it over with. Others, such as China, must at least make an attempt at a fair trial in order to soothe Western critics.
... you're an idiot.
Worse, you're the sort of idiot who, instead of having any facts to back up outrageous allegations, says "if you only knew what I know, then you'd agree with me".
That's intellectual fraud.
Speaking as a communications security hardcase, and also as someone who has worked in a DoD-funded research lab, and also as someone who secured data in that lab using PGP...
... what the hell are you talking about?
Really?
Nothing happened to me for using PGP to secure a couple of files. In fact, I don't think anyone even noticed. Security in those places isn't as tight as you're making it out to be.
Answer the question, please. Do the power analysis--it would take an optimal computer about one year at a constant 250 megawatts of power to break a 128-bit cipher.
If the NSA is so advanced that it has perfect computers running at a cryogenically-cool 3.2 Kelvins and hooked up to its own nuclear power plant just to flip the bits, I'd really like to know about it.
I'm not being facetious here. If you have any hard facts to back up your assertion, I'd like to hear them.
Disclaimer: I am not, in any way, speaking for my company. More than that, I don't have my reference books handy, so I'm going purely from memory--I may be off on a detail or two.
PGP (more accurately, programs which implement the OpenPGP specification) is not insecure when properly used. By "properly used" I mean choosing a reasonable size for asymmetric keys, choosing a reasonably good passphrase, and practicing good email discipline--unrevealing subject headers, not sending anything cleartext which could compromise your key, etc.
Is it trivial to use PGP/GPG properly? No, and that's the biggest problem with PGP/GPG. Still, that's not what Jon Katz's source said; the strong implication was that government agencies could, either by brute force or cryptanalysis, break a PGP-encrypted email in a day. So let's address that now.
In order to break a PGP/GPG encrypted email, either the asymmetric or symmetric components of its cryptography need to be broken. Breaking the asymmetric component requires either an efficient way to factor large numbers[*] (for RSA) or an efficient way to solve the discrete logarithm problem[**] (for El Gamal).
After more than twenty years of study, such efficient algorithms remain Holy Grails of cryptographic research.
Breaking the symmetric component requires some efficient way to break the cipher. By "efficient" I mean better than brute force, better by several orders of magnitude. Being ragingly paranoid here, I'd expect government agencies (DGSE, NSA, etc.) to be able to break 80 bit ciphers by brute force. The weakest [+] cipher in the OpenPGP spec is Triple DES at 112 bits. That still exceeds governmental capabilities by a factor of four billion or so.
Basically, the claim that "the NSA can break PGP-encrypted email in a day" is so much hogwash.
That being said, there are undoubtedly attacks which government agencies can perform against ciphers. Cryptanalysis is just very rarely one of them. It's far cheaper for the government to Van Eck your monitor, or break into your apartment and plant eavesdropping devices, or crack your box to grab your private key and plant a keypress sniffer to take your passphrase. And if you're sending stuff which is so tempting to the government that they'd go to this effort, then you probably want to invest in something more than PGP/GPG.
There are many attacks which exist against PGP/GPG. It's just that, to the best of my knowledge, there are no good cryptanalytic attacks against PGP/GPG.
[*] Strictly speaking, this isn't true--we don't know for a fact that you have to come up with an efficient factoring algorithm to break RSA. It seems to be strongly implied, but there has never been a formal proof of this requirement.
[**] This isn't true, either--see the above footnote. Interestingly, coming up with an efficient factoring algorithm doesn't help you solve discrete logarithms, but an efficient solution to the DLP will give you an efficient factoring algorithm.
[+] 3DES is "weakest" in the sense that it has only a 112-bit keyspace, as opposed to the 128-bit keyspaces of the other ciphers used by PGP/GPG. There are some extremely esoteric attacks against 3DES which bring down its complexity somewhat, but it's still solid as a rock. 3DES has survived a quarter-century of cryptanalysis and nobody's been able to hit a home run against it yet; this means that 3DES, while "weakest" in the sense of keyspace, is probably the strongest cipher in common use today.
IANAL, but my father is a judge, my cousin is a DA, another is an ex-cop, another is... well, you get the idea. My experience is practical, not professional, and I am not suggesting that this is in any way a substitute for real legal advice. That being said:
/.ers seem unaware of just how mercurial juries can be.
:)
/. readers. Instead, just remember what I said about judges; they hate being overturned, and they hate being humiliated.
:)
1. YOU CAN BE SUED FOR ANYTHING.
There are laws on the books which are meant to cut down or eliminate frivolous lawsuits, but judges rarely reprimand attorneys for wasting the court's time.
2. LAW REALLY DOESN'T MEAN ALL THAT MUCH.
As soon as the jury is seated, it's an entirely different ballgame. Juries occasionally follow the law with diligence and probity, and occasionally they completely buck the judge's counsel and do whateverthehelltheydamnwellplease.
In this instance, a jury wasn't seated--the reason why I bring it up is because many legal proceedings do involve juries, and most
3. TEMPORARY INJUNCTIONS ARE JUST THAT.
Temporary, and injunctions. Judges are prickly people, as a rule. Most of them are control freaks of such a high order as to dwarf absolutely any other profession out there--including doctors. There are two things which judges universally fear, though: one is being overturned on appeal, and the other is being humiliated.
If someone comes before a judge and says "Your Honor, this bad person over here is doing something which will cause substantial and irreparable harm unless you do something to help me right now", the judge has three choices:
* He can schedule a full hearing, and tell the aggrieved party "well, let's wait two or three months and just handle a full, permanent injunction hearing"
* He can execute summary judgment and declare that no such irreparable harm exists, and refuse to do anything
* He can issue a temporary injunction, and schedule a permanent injunction hearing for later.
... Remember: judges hate to be overturned on appeal and they hate to be humiliated. If the judge chooses the first or second option, that leaves him (a) free to be overturned, and (b) if the judge is wrong and irreparable harm does occur because the judge didn't issue an injunction, the judge will be publically humiliated.
Judges, therefore, overwhelmingly tend to be very lenient with temporary injunctions. Many of them claim that this leniency is in everyone's best interests, and it may well be--but I'm a cynic, and this colors my analysis.
4. TEMPORARY INJUNCTIONS ALWAYS EXPIRE.
This one is simple. Temporary injunctions always expire, and permanent injunctions last for as long as the Court (not the parties involved--at least, not necessarily) wants them to. In order to move from a temporary injunction to a permanent injunction, well--let's skip the procedural details, because it's likely not interesting to
This gives them extremely strong motivation to consider permanent injunctions very carefully. If they misstep on procedural or logical grounds, it's cause for overturn on appeal; and if they make the wrong decision and someone loses their shirt as a result, then the judge gets humiliated.
So judges tend to view permanent injunctions with a much more careful, and skeptical, eye than they do with temporary injunctions.
... But, as I said, I'm not a lawyer and I don't know beans about the legal system. You'd be a fool to think that this is anywhere near competent legal advice.
C# permits pointers (and everything associated with them) and the disabling of garbage collection. Neither of these can be duplicated in Java. It might be able to implement a subset of C# which would be more Java-friendly, but not the full set of C#.
#include "disclaimer.h" /* see my sig */
Is the wireless Web secure? No. Is the Web secure? Also no. There is no difference, realistically, between wireless and wired networks. Have you ever used a satellite link to send data across the globe? A lot of people have and never realize it. The Net is a hybrid network; wired and wireless coexist equally. They only exist to transport data, and data sent in the clear is just as vulnerable on a wire as it is via wireless as it is via smoke signal.
Remember that a network is only as secure as its weakest node. Unless you take significant precautions, your Web transactions are insecure, period. Even HTTPS isn't a great solution.
(I am an InfoSec professional IRL, but this is absolutely not professional advice. Nor am I speaking for my company.)
Who says you'd even have to go to the trouble of actually encrypting it. Well encrypted data should be indistiguishable from randomness.
Not quite. Look at a PGP message, for instance. Most people would probably agree that, properly used, PGP provides good encryption--but it also has a very recognizable message format. There's an entity which specifies the algorithm to use (IDEA, 3DES, CAST128, etc.), an entity which is the sender's public key, an entity which is... etc., and so on. If the PGP message format was not precisely defined and recognizable, it would be vastly more difficult to use PGP. ("Damn! Err, okay, so what algorithm did they use to encrypt this, anyway?")
If all you want to do is run data through a cryptographic algorithm, then yes, it will come back out as something which should pass every statistical test for randomness.
Running data through a cryptographic system, what comes back out should be easily recognizable as the output of that specific system (unless, of course, the system was specifically designed to be indistinguishable from random noise).
Very few people use cryptographic algorithms by themselves. Most of the time, when people say "I encrypted it with Blowfish", they mean "I encrypted it using a cryptosystem which used Blowfish for its cryptographic core".
I am an InfoSec professional, but this is not professional advice. (Gads, I hate lawsuit-happy cultures like ours...)
Bruce Schneier's YARROW is the only PRNG I'm aware of which has actually gone through formal cryptanalysis. I'm not overly fond of YARROW--it's extremely slow with its 3DES/SHA-1 core--but the fact that it's been cryptanalyzed makes it much more trusted than almost any other PRNG.
Substituting a fast cipher like Blowfish or an AES candidate, and replacing the hash algo with MD5 or somesuch, would result in a much faster YARROW. Unfortunately, this also invalidates the cryptanalysis, since the modified version wouldn't have undergone the same level of cryptanalysis: still, if I remember correctly, YARROW is intended to be both hash- and cipher-agnostic.
IRL, I'm a full-time PGP hacker for PGP (part of Network Associates)--so keep in mind that my perspective may be biased by my employment. (And as always, I am not speaking for my employer, and this post does not constitute professional advice.)
:)
Basically, it proved vulnerable to some esoteric attacks. It's no longer as strong as was once thought; while it's still secure, 4.5 rounds have been broken (last I heard--considering how quickly the field moves, it might be more now.)
Between its small security margin, its rather slow operation speed and the obnoxious patent (obnoxious both in terms of cost, and in terms of how difficult Ascom-Tech A.G.--and now apparently Entrust, too--made it to obtain one), people have just decided to use other ciphers.
IDEA's big selling point for the longest time was that it was the only trusted replacement for DES (barring 3DES, of course). Since we now have literally dozens of trusted replacements for DES, why bother with IDEA? Blowfish is well-trusted and pretty snappy in its operation; I'm not as fond of CAST as others are, but it's held up rather well (well enough to have been a strong AES contender).
When we have ciphers which are faster, less patent-encumbered and offer a larger security margin than IDEA, why should we continue to use IDEA?
I am an InfoSec professional IRL, but I am not speaking for my employer, yadda yadda, this is not professional advice, insert standard disclaimer.
First: I've never heard of this fellow. I don't recall seeing his name in any of the crypto journals. I don't recall seeing any particularly clever attacks from him in the past. Protocol design is tough; it is an exceedingly nontrivial task, even harder than designing new algorithms. Anyone who says they have a great new protocol is most likely lying, unless they're a Tuchmann, a Coppersmith or a Schneier.
Always assume all new protocols are full of it, until enough time and attacks have gone by to give confidence that the protocol is only mostly full of it.
Second: this system is not secure. Repeat after me: a one-time pad is secure as long as it's only used once. The likelihood of a birthday attack is orders of magnitude more likely than he's making it out to be. The reason for this is because Net traffic is not uniform; certain places tend to be "hot" and others "cold".
Let's have a thought experiment. Let's say Slashdot begins to implement this system, and has a few thousand "pad blocks" available. This means a few hundred megabytes of purely random data--let's completely ignore the practical difficulties of purely random data for now and just assume we can do it.
When Alice decides to store something unpopular and encrypts it with Pad(s) alpha, beta and gamma, so that Bob and Charlie can read it later, what's Alice going to do? -- Probably use one of the first twenty pads listed. Why? Because people are lousy at choosing random numbers. If you ask someone to pick a number at random, they're most likely to pick a number between one and ten, not one and fifty billion. Things that are at the head of a list get selected more often than those that aren't.
Let's say that Slashdot randomizes these pads, though, so they always come up in an unpredictable order. (Never mind the practical difficulties in how to do this in the first place. It's a thought experiment. Just keep alive in the back of your mind the fact that (a) we've had to create hundreds of megabytes of purely random numbers, and (b) we have to present them to people in a purely random way.)
After some mathematics, Alice's super-secret Neiman-Marcus cookie recipe is now pretty much totally obscured. She posts the recipe to a Website, and then tells Bob and Charlie, "Psst! I posted the information to this site. Find pads with IDs of [she recites their IDs] and use that to recover the information!"
At that point the secret police storm in, having been eavesdropping on the entire conversation. They throw Alice, Bob and Charlie in jail. They go to the website, pull the information, get the pads and read the Neiman-Marcus Cookie Recipe for themselves. Guess what? This protocol has completely, totally and utterly failed.
The naieve response is to say "well, they wouldn't say it in the open... they'd use encrypted email to share the pad IDs!" Okay, fine. All that's happened is the encrypted email is the weak link in the security; if that goes, the entire scheme falls apart.
Now recall those two extremely thorny problems from before. Hundreds of megabytes of purely random data are very hard to come by, and purely random presentation of random data is very hard to do. Add in the implementation weaknesses to the weakness of the communications channel between Alice, Bob and Charlie, and you've got a protocol which has very little merit.
This protocol solves a problem which doesn't exist, as far as I can tell. Now, admittedly, I'm not the sharpest knife in the drawer and I'm also bone tired and I could be totally misunderstanding what the goal of the protocol is.
But for a secret-sharing protocol, or as a way to securely store information in a way which is deniable, it's pretty dismal.
I'm an InfoSec consultant IRL, but this is not professional advice. (And soon I'll be a full-time paid PGP hacker. Yay. )
:)
:) I wouldn't use it in a production system, but when it comes to noodling around with novel crypto (to quote Enoch Root), GOST is my favorite.
There are literally dozens of perfectly good ciphers out there. Blowfish, 3DES, Twofish, IDEA, RC2, RC4, SEAL... the list goes on and on and on.
No two ciphers are exactly identical. Cipher selection is based on these minute tradeoffs between ciphers. For instance, 3DES is solid as a rock but is quite slow. I wouldn't use 3DES to encrypt a high-bandwidth realtime communications link, obviously, although I would readily use it to encrypt a 100k file on a disk.
Blowfish is very fast, but key setup is slow--so I wouldn't use it in an environment where keys would be changed frequently.
IDEA is strong and fast, and is well-suited in a whole range of endeavors. It's also encumbered by patent, though, and some of my clients don't want to shell out money to Ascom-Tech A.G..
... In the final analysis, cipher selection is dictated more by secondary factors than by cipher security. There are so many strong ciphers out there that we can engage in personal preference and pay attention to "other details", like performance. It's pretty simple stuff, really. I have a harder time selecting a mode for a cipher than I do selecting a cipher.
My own personal fave cipher is GOST, mainly because you get retro-cool points for using it.
I am an InfoSec professional IRL; however, I'm not a college prof and I've never taught a class beginning to end.
1. COVER FAILED PROTOCOLS.
The field is littered with broken protocols and algorithms. Some of them are broken because they're stupid (so study why so many people thought they were smart). Some are broken because they got overtaken by technology (so cover how the protocol left itself vulnerable to technology [1]). Some are broken because the assumptions underlying the protocol are incorrect [2]. Some are... etc. Study the failed ones closely, and learn why so many people thought for so long that they were good.
2. STUDY PRACTICAL AND THEORETICAL DIFFERENCES.
IPsec is a very good protocol in theory; in practice, it's painfully mediocre. IPsec works well as a lesson for how "the best-laid plans of mice and men gang aft agley"; somewhere inside of it there's a beautiful, small protocol screaming to get out, but it gets bogged down in elephantine bulk.
Theoreticians tend to create complex protocols which are damnably difficult to implement well (but when they are, they tend to be nice). Those who take a more practical approach create simple algorithms which can be implemented well, but don't address subtleties.
For examples, see [3] and [4].
3. STUDY THE MISTAKES PEOPLE KEEP ON MAKING.
There are very few really new protocols; people just keep on re-inventing old ones. They also make the same mistakes over and over again. We've known ever since WW2 that poor passwords lead to compromised ciphers. We've known that re-using one-time pads make it trivial to cryptanalyze data. Yet, certain nameless day-trading firms limit user passwords to six alphanumerics, case-insensitive--that's a weak password. Yet, we sometimes see KAK ciphers (OFB ciphers) being used with a repeated IV--that's the same as repeating a one-time pad.
Programming errors are even more common than protocol errors, and can be just as damning [5].
[1] DSA, for instance, originally used a 512-bit modulus. This was way too short for long-term security, and they had to revise it to 1,024 bits almost immediately. It is likely that in the not-too-distant-future, DSA will have to be changed yet again.
[2] Atjai-Dwork and Cramer-Shoup are good examples here.
[3] Kerberos is an example of a theoretically sound protocol which is difficult to implement well in practice. Check the modifications which have been done to Kerberos--for instance, why PCBC mode was used for crypto and why it was changed to CBC mode.
[4] Schneier has some good examples of digital-cash and digital-voting schemes which are practical, but fail to address subtleties.
[5] Check out PGP's latest exploit.
I am an InfoSec professional IRL, but this is not professional advice.
:)
==========
Ref: point 2, "Remember when 128 bit keys was way too big to be factored? I do, and I'm all of 28 years old."
128 bit keys were never considered too large to be factored. Various people were positing RSA-129 as being secure back in the '70s, but that was 129 *decimal digits*, not *binary digits*. (I may be off on the exact 129 figure--it was about that, though.)
To brute-force a 128-bit number requires you check every prime through 2^64. This is not very difficult. Using an intelligent factorization algorithm will make factoring a 128-bit number trivial.
To give a rough comparison, 2^20 is approximately equal to 10^6. 2^20 raised to the sixth power is 2^120, add on another factor of 2^8 (which is approximately 10^2)... you're looking at 10^6 raised to the sixth (10^36) with another factor of 10^2, for a grand total of 10^38.
Factoring a 38-digit number is not very hard. Factoring a few *hundred* digit number is nontrivial.
I am an InfoSec consultant IRL; and in the course of my job, I've occasionally stumbled across some interesting tidbits (which credit-card companies use repeated-XOR encryption, which HMOs keep medical information secure with DES, etc). I have heard reports, but have not been able to verify their accuracy, that at one time Russia's Strategic Rocket Forces were using 3DES (with three independent keys) to secure their nuclear-launch codes.
If true, that suggests a very high degree of confidence in 3DES.
I've got to say that 3DES isn't my favorite algorithm, but properly implemented, it's an extremely secure algorithm. Unfortunately, many software DES implementations manage to screw up the DES spec (probably, I think, due to the infernal complexity of DES).