Slashdot Mirror
DMCA Attacks: NAI Tells Sites To Remove PGP (Updated)
daecabhir writes: "I am on Declan McCullough's excellent policy and technology mailing list, and received this article on Declan's Politech web site. Basically, Network Associates now appears to be using the DMCA to force sites that provide access to the "free" versions of PGP to cease and desist, if this is any indication. Unfortunately, I think that Network Associates may well be within their rights with regards to 'their' intellectual property, even if I disagree with the manner in which they are going about things." Update: 05/22 13:55 GMT by T : Looks like this wasn't the whole story, and in fact NAI was only objecting to a site with the commercial version of its software -- read below for more.
Grant Bayley writes: "The hype being generated by the "NAI pulls out the DMCA stick" postings and the spectre of PGP being "removed from the Internet" is entirely
bogus, and provably so with a little bit of fact checking.
Looking through the Google cache, it becomes very clear very quickly that crypto.radiusnet.net was hosting a copy of the commercial version of the software - not a copy of the PGPi (aka freeware) version of the PGP product. Given that this is the case, NAI is well within their rights to demand the removal of the files.
You can confirm this in the Google Cache.
We tell other countries what to do, they do it.
It's called Pax Americana and it's been the international order since 1990.
I have been pwned because my
Network solutions was founded by ex CIA and NSA guys and then sold to SAIC which who's sr mangment are all exspooks.
you make funnel cakes from sperm
I used to and your mom loved them, but I had to give it up. The boiling oil splashing out wasn't good for my foreskin.
I have been pwned because my
Really. You're painfully uninformed.
That could very well be. Reading your reply shows I'm in good company.
RFC2440 (plus RFC2015, 3156, etc.) are extensible...
Um, no, they aren't. They're good for public-key and symmetric encryption, but, despite what you learned at the university, public-key and symmetric aren't the only choices available.
I'd like to plug in a one-time pad, if that's OK with you. Utterly unbreakable. I like that. OpenPGP doesn't seem to easily support that.
I'd also like to support trivial encryption methods, like replacing 'a' with 'c', etc. Yes, any three-year-old would be able to break it. But if you make it easy for people -- including novice users -- to pick and choose from these trivial algorithms any number of same and apply them to their message it would require some fantastic coding on the part of the NSA to automatically decipher it all.
Yes, if they want to devote GS-7's to the task of decrypting a specific message they'll be able to do it. But they won't be able to automate the decryption of all our messages. They'll have to assign each to a GS-7.
There are more of us than there are GS-7's. It's not a subtle point I'm making here, is it?
Microsoft CAPI provides just this. GPG Made Easy (GPGME) also makes it almost trivial to incorporate crypto support into your application. (ObDisclosure: I'm working on C++ bindings for GPGME, so I'm biased.)
I wouldn't say your biased. Just defensive. For what it's worth, I think you're doing us all a great service by focusing on exactly what you're doing.
I just think you're missing my point. For instance, you've only listed two API's up there, for two families of email products. There are dozens more applications that are candidates for this. And all the work is being done to support formally correct algorithms. What I'm saying is that there is a value to worthless algorithms (as well as uncrackable algorithms like one-time pads) that deserve to be put in the mix too.
RTFFAQ. OpenPGP supports more algorithms than you can shake a stick at. For instance...
Yes, I've read the FAQ. I don't see one-time pads listed there. The one algorithm that is provably undecipherable and it's not available to me. Maybe some of you guys need to read the Frequently Asked Requests list?
No. In fact, I personally dislike the fact that most PGP implementations (including GnuPG) support so many algorithms...
Please try to look at this from the point of what goes on at the NSA. Have you ever heard of the expression, "low-hanging fruit"? Most of what the NSA is called on to decipher is "low-hanging fruit." It is stuff that they can easily decipher by simply inputing the file into some program running on some supercomputer somewhere.
What we should want to do is make it hard for them to guess what program to feed a encrypted file to. If you have 10,000 stupid and trivial encryption algorithms that can be broken by three-year-olds you'll still need 10,000 three-year-olds to sit down and figure them out if you want to crack them. If you have people out there encoding their messages using any combination of those 10,000 trivial encryption algorithms you have 10,000 factorial problems to work out.
I'm repeating myself, but the point can't be stressed strong enough. If the NSA wants to decrypt any one of these, they can. But if everyone were to adopt this kind of approach, the NSA would not be able to routinely decrypt our messages. They wouldn't be able to simply feed them all to a computer, they'd have to assign GS-7's to the task, and it would take time... lots of it. The scenario I'm envisioning would see the agency demoralized within a year, and their masters dissatisfied with their work product within another five years.
The analyst is already going to know what algorithms you're using. The way you plan these things is to assume the analyst has access to tens of thousands of times more computing power than exists in the world, tens of thousands of times more memory than exists in the world, knows you better than your wife does, and knows every last detail of your cryptosystem except what your key is.
WRONG!!! If we make it easy for users to come up with weak, but utterly wacky, algorithms, how will they know??? How do they know I'm exclusive-or'ing with a Erica Campell jpeg? Hmmm? Did you tell them?
If we give users an interface that lets them improvise their own ridiculous encryption algorithms, and layer them atop the more secure algorithms you're talking about, the analysts will no longer be able to assume what algorithm is being used. And that's my whole point.
That's what we need to change. We can't let them simply assume anymore. We need to make them really work for our data.
And yes, I am a cryptographer.
No offense, but that's your problem. I'm not taking about the art of cryptography, per se. You can't see the forest for the trees. Please think about what I'm saying. Don't think about the math of it, think about what the GS-7 at the NSA has to do to deal with what I'm talking about.
Please go read this book: Codebreaking, by Rudolf Kippenhahn. You have a critical misunderstanding of how cryptanalysis works. It doesn't work by a series of "try this, then try that, then try...
You're talking about cryptoanalysis that focuses on a single encrypted file. I'm talking about cryptoanalysis as it occurs in a data shop, where there are umpteen candidate files that need to be decrypted, and some GS-7 who's pushing all the buttons to see that the right files go to the right programs.
I concede that what I'm talking about is crackable. Actually, I personally don't mind that the NSA is able to target a specific communication and decrypt it. What I object to is their being able to summarily decrypt all our communications simply because they can.
You should be familiar with the use of chaff in encryption. What I'm suggesting isn't too different from that, except here it would be introduced to the system at a macroscopic scale.
I would bother responding to your last comment about why PGP is "weak", but really, it's c
This comment was cut short. If you know that PGP doesn't save the checksum, please say so. Or are you defending its inclusion?
Is this truly the only Earth I can live on?