Yes, the recipient would have to know how you've encrypted the message, and if that information is included in the header it makes the scheme worthless. The encryption being used would have to be agreed upon out-of-band. I don't see that as being as onerous as everybody thinks it will be. It's nice that there is a way to encrypt messages to people you've never met, but I have no need to communicate securely with people I don't know.
When I want to send information securely, it is to somebody I know, who've I've met, who I talk to over the phone, etc. Maybe it's source code, contract negotiations, sweet nothings in her ear.
It seems to me that we are losing a lot by buying into only a few algorithms. We're putting all our eggs in one basket, so to speak. If these ciphers are breakable, then we're allowing the NSA to automate all of their cryptoanalysis!
I disagree that this would have to be popular in order to be effective. Or, maybe it depends on what you mean by popular. If the ability is widespread and some number -- even if it is only in the hundreds say -- are using the software, then the NSA has to code for it, right?
A lot of things have to be done right. The software has to have a very easy-to-use interface that generates the algorithm. This algorithm then has to be representable as a number that can then be communicated to the desired addressee who then can enter that number into her system and associate it with email coming from you.
Again, the algorithm being used here can sit atop something more robust, like triple-DES, so it wouldn't be easy to crack at all, or at least, no easier than cracking triple-DES, so there is a security factor that can be advertised here... noone need shy away from this approach because it isn't strong.
What we're doing now is giving the NSA a very focused point of attack. By getting everybody to use as many different encryption standards as possible, we promote the demise of Echelon-like activities.
Think of obscurity as something that sucks for an individual application, but which scales really really well. After a certain point, it becomes overwhelming. Yes, the NSA will still be able to target specific messages, but this business with sweeping through everybody's traffic in due course is effectively finished.
Umm, call me crazy but I think that one-time-pads are a form of secret-key symmetric cipher.
You're right of course, I've gotten in the habit of regarding one-time pads as being in a class of their own. Something about their being the only kind of crypto that will survive quantum computing.
But I guess it doesn't say that in the textbook.
Otherwise, the rest of your post is just garbage. Weak but "unknown" algorithms do not provide security, even millions of them.
Clearly, you haven't read anything I've written. Either that or you're a idiot. Don't feel bad, there are lots of idiots here, you're in good company.
The point to the trivial encryption algorithms isn't that they'd pose a challenge individually to the NSA, but rather, when taken together, they'd pose an enormous logistical problem for them... one that would probably be insurmountable.
The trivial algorithm could always be applied on top of a more robust one.
The trivial algorithm would have to be something that could easily be created by a novice, by being able to select from a list of thousands of prepackaged trivial algorithms perhaps, and then chaining them together so that the number of tries required by the NSA computer would be on the order of 10,000 factorial, say.
Think of it as insurance. The NSA may not be able to crack some of these more robust algorithms, but then again, they just might. All of you are looking at this from the point of view of cryptographers. I'm looking at it from the point of view of somebody who is running thousands of jobs a day trying to decrypt a steady stream of traffic assigned to them.
Whatever. If you don't get it by now, there's no use. You'll just have to wait for the textbook.
You're a programmer; that's a program for a first-year student.
Actually, a small child flipping a coin can implement the algorithm, but that isn't my point. The one-time pad is the only algorithm that can be said to be absolutely secure provided the pad can be exchanged reliably. That makes it ideal for certain applications.
There's so many possible formats for a one-time pad - I can't imagine a generic program that would support your CD-ROM idea.
Are you kidding? All you would need to do is save an index value somewhere. When encrypting a message, exclusive-or the message with the random data on the CD at that index value, then increment the index value by the amount of data encrypted for the next use. Vice versa when decrypting. Very simple.
Given how insecure one-time pads are, if not used carefully, and how much a PIA they are to use, if used carefully, I really don't see the point in such an addition to GPG.
You're grossly exaggerating the insecurity here. Unless you have every password you use memorized, you have some written down somewhere or stored in some device. The risk of using a one-time pad is the same, provided you've securely exchanged the pad in the first place (no big deal.)
There's no evidence they can break 3DES or Blowfish.
Yes, of course the NSA will announce when they've broken 3DES or Blowfish.
They would be able to decrypt any message they wanted to; half the time they would just feed them to a computer, the computer would run the top 50 trivial algorithms, and spit out the answer.
Yes, that works for 50 trivial algorithms. What I'm talking about is allowing novice users to create any number of trivial algoritms, and to combine any number of same together with stronger algorithms to create a truly impossible job for the NSA. It wouldn't be 50 tries they'd have to do, it'd be more like 10,000 factorial.
OK, I see/. truncates messages, it's happened to my reply (first time I've seen it happen to me) and it happened to your message. I'm particularly interested in how you were going to finish the following sentence:
I would bother responding to your last comment about why PGP is "weak", but really, it's c
Again, I was making a big deal about the checksum appearing in the zip file that PGP creates before encrypting.
Dude, I've read through all of Schneier's "Applied Cryptography", First Edition, and spent many an hour comparing his Second Edition with his first.
Read "Secrets and Lies" too.
I've implemented in C any number of encryption algorithms, have invented a few of my own too actually (yes I know, LOL.) I got OpenSSL to compile and work the way I wanted in both Linux and Windows environments, um, OpenSSH too. PAM. Etc.
I'm no super-duper-math-genius or anything, but then, clearly, neither are you.
I think you're just having a bad day. A lot of people here don't get the pussy they need, and I'm thinking we should elect you as our leader... you've got all the symptoms and you don't seem to mind showing it. I salute you.
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?
I'll take your word for gnupg's pluggability, since no mention seems to be made of it in the documentation... but I'll read it again.
However...
I think you miss the point regarding the value of increasing the number of algorithms. The complexity increase is not n times but rather n factorial. Algorithms can be applied in daisy-chain fashion upon other algorithms. Even a trivial algorithm works here.
Yes, a decent cryptoanalyst will tear apart a trivial algorithm, but how many decent cryptoanalysts are there? More than the number of people who can choose any combination of installed algorithms via point-and-click?
No.
Again, we've been trained to think about this as a problem of protecting a single channel. All of that is still valid, for that one specific problem. The problem of how to get the NSA to give up this travesty of a cause is quite another, and it is realizable only by demonstrating to them the impossibility of the problem they are attempting to solve.
For instance, does gnupg allow me to plug in a one-time pad as an encryption algorithm? I don't think so. The gui I'm envisioning would. Yes, there are practical considerations in the use of the one-time pad, but once those are met, the resulting communication is impervious to cryptoanalysis, regardless of the technology the NSA is wielding.
For instance, two friends at graduation who are going their separate ways, agree to rip a CD using/dev/random, make a copy, and use those 680MB to encrypt the emails they send to one another... for life. Very cool, very doable... very unbreakable.
Get enough people doing that, along with people using the encoder rings they got in their box of Cap't Crunch, and rot13, and all the trivial extensions of all the serious encryption algorithms and the NSA will be swimming in complexity... a kind of complexity they can't easily leverage their hardware to tame.
I know gnupg has made some very big strides in this area, but clearly, now is the time to devise a framework upon which popular encryption is allowed to survive PGP.
The point isn't whether the geeks can do it. The point is whether some poor, persecuted soul in some totalitarian country, like -- um, you know -- can click a button and send an email out of the country or to his best friend, securely.
Clearly we would like to see front-ends developed for all the popular email applications that can accept code implementing any kind of encryption scheme whatsoever, and encryption algorithms that can fit into any popular email application available.
If somebody comes up with a new encryption algorithm, they shouldn't have to write code to support Evolution, Eudora, Outlook Express, so forth and so on.
Likewise, somebody should be able to write a front-end for a email application according to a specific API and expect to see every available encryption algorithm thus far implemented available from within that email application.
And of course, it all needs to be open source. If anything needs to be open source, it is this.
gnupg is great, but it presumes a single algorithm, doesn't it? Wouldn't it be much better to make it easier to introduce new algorithms into the mix? Put yourself in the position of the GS-7 analyst sitting in Virginia who has to run all these decipher jobs. If he gets to *assume* that the encryption being used is pgp-style, his workload is modest, he just needs to feed the file to the program.
But if he first has to figure out what algorithm is being used, suddenly his job becomes many orders of magnitude harder. Especially if there are hundreds if not thousands of algorithms out there, each and every one available to the common man for his use.
I know we're not supposed to rely on obscurity for encryption, but that presumes your only interest is in protecting a single channel of communication. If your interest is in protecting *all* channels of communication, obscurity becomes viable. Something as trivial as taking the output of gnupg and exclusive-or'ing with a Erica Rose Campbell jpeg would add another - if - statement to the NSA's decryption code. Add another 100 jpegs every day and very quickly the NSA's job becomes very, very hard.
I never liked PGP. They zip before encrypting, and I could never get an answer from Zimmermann as to whether or not the checksum survived the zip. If the checksum survives, all the NSA has to do is unzip every try at an encrypted file and see if the checksums match. Strip out the checksum, and their job becomes much harder. The checksum needs to go.
The article seems to indicate that while Xbox is placing great emphasis on networking, Playstation is not.
I have to believe the Times errs here. Sony after all owns Everquest.
Or... is it because Sony owns Everquest that they think they have network games covered?
As addictive as EQ is, it isn't a substitute for robust game network that allows for the development of many different kinds of games... or is it? Will VR worlds be the be-all-and-end-all of network gaming, even well into the future?
I think that's a risky gamble. Sony should put more resources into providing better support for more generic network games, if only because Microsoft is doing it with Xbox.
Those Israelis who were caught running explosives probably dumped their cargo somewhere around Northern Cal, where it blew up, and triggered some kind of post-Nevada-testing-site showdown with the San Andreas Fault.
Everybody should just take Sony to small claims court!
Bring your fucked-up iMac -- or buy an iMac and have it fucked up by Sony first -- and bring the iMac to small claims court, asking for Sony to fix your iMac.
If everybody did this, what would Sony do? Deploy a lawyer to every one-horse town in America defending these claims?
If they did, the cost would be exorbitant beyond belief! If they didn't, the cost would be exorbitant beyond belief!
Get all the little companies who are at risk from these filthy blood-sucking parasites to pool their resources and sue them back under the rock from whence they came.
How many businesses use web form entry? 1,000,000? If you just get 10,000 to kick in a $1000 each you'll have these dogs back to licking their balls clean in no time.
I can run X too, using the dummy nv driver included with the distribution.
When I try to get the real nvidia driver to work, whether it be the one downloaded using SuSE's updater or one I download myself from Nvidia I invariably end up in 640x480 mode with a desktop the size of Kansas.
Changing window managers doesn't seem to help, at all.
I have the same problem with my Logitech Optical Mouse. And I made a big post earlier complaining about there being no info, stickers, etc., but this is easily more irritating.
Long time SuSE user here, who in the past always went with the "install everything" option.
With 8.0, there was no "install everything" option -- or I missed it -- so I picked "Default KDE w/ Office".
You'd expect that info would be installed with such an option, yes?
The reason I needed info was because SuSE is still using lilo, and I'm sorry, but grub simply rules, alpha or not, so I had to do that bit manually.
Also, I have a GeForce4 TI 4600 and I can't for the life of me get the thing to work right (yes I have the latest nVidia drivers), but I attribute that to it being a new card and all and fully expect somebody else to figure it out for me. Not a big deal since I stay in text mode most of the time anyways (use the GeForce for Windows games.)
Oh, yes, and one last thing... NO STICKERS!!! SuSE always has an assortment of somewhat-silly-but-nevertheless-cool stickers I can put on things and regret having done so later, but none were to be found in 8.0.
Slashdot Mirror
How about 'STUPID', 'MORON', and 'RETARD'?
'GREEDY', 'SELF-SERVING', and 'HEARTLESS BASTARD' are available as well.
I'm sure we can come up with more. Every one unique. Every one identifying these people for exactly what they are.
Yes, the recipient would have to know how you've encrypted the message, and if that information is included in the header it makes the scheme worthless. The encryption being used would have to be agreed upon out-of-band. I don't see that as being as onerous as everybody thinks it will be. It's nice that there is a way to encrypt messages to people you've never met, but I have no need to communicate securely with people I don't know.
When I want to send information securely, it is to somebody I know, who've I've met, who I talk to over the phone, etc. Maybe it's source code, contract negotiations, sweet nothings in her ear.
It seems to me that we are losing a lot by buying into only a few algorithms. We're putting all our eggs in one basket, so to speak. If these ciphers are breakable, then we're allowing the NSA to automate all of their cryptoanalysis!
I disagree that this would have to be popular in order to be effective. Or, maybe it depends on what you mean by popular. If the ability is widespread and some number -- even if it is only in the hundreds say -- are using the software, then the NSA has to code for it, right?
A lot of things have to be done right. The software has to have a very easy-to-use interface that generates the algorithm. This algorithm then has to be representable as a number that can then be communicated to the desired addressee who then can enter that number into her system and associate it with email coming from you.
Again, the algorithm being used here can sit atop something more robust, like triple-DES, so it wouldn't be easy to crack at all, or at least, no easier than cracking triple-DES, so there is a security factor that can be advertised here... noone need shy away from this approach because it isn't strong.
What we're doing now is giving the NSA a very focused point of attack. By getting everybody to use as many different encryption standards as possible, we promote the demise of Echelon-like activities.
Think of obscurity as something that sucks for an individual application, but which scales really really well. After a certain point, it becomes overwhelming. Yes, the NSA will still be able to target specific messages, but this business with sweeping through everybody's traffic in due course is effectively finished.
Umm, call me crazy but I think that one-time-pads are a form of secret-key symmetric cipher.
You're right of course, I've gotten in the habit of regarding one-time pads as being in a class of their own. Something about their being the only kind of crypto that will survive quantum computing.
But I guess it doesn't say that in the textbook.
Otherwise, the rest of your post is just garbage. Weak but "unknown" algorithms do not provide security, even millions of them.
Clearly, you haven't read anything I've written. Either that or you're a idiot. Don't feel bad, there are lots of idiots here, you're in good company.
The point to the trivial encryption algorithms isn't that they'd pose a challenge individually to the NSA, but rather, when taken together, they'd pose an enormous logistical problem for them... one that would probably be insurmountable.
The trivial algorithm could always be applied on top of a more robust one.
The trivial algorithm would have to be something that could easily be created by a novice, by being able to select from a list of thousands of prepackaged trivial algorithms perhaps, and then chaining them together so that the number of tries required by the NSA computer would be on the order of 10,000 factorial, say.
Think of it as insurance. The NSA may not be able to crack some of these more robust algorithms, but then again, they just might. All of you are looking at this from the point of view of cryptographers. I'm looking at it from the point of view of somebody who is running thousands of jobs a day trying to decrypt a steady stream of traffic assigned to them.
Whatever. If you don't get it by now, there's no use. You'll just have to wait for the textbook.
You're a programmer; that's a program for a first-year student.
Actually, a small child flipping a coin can implement the algorithm, but that isn't my point. The one-time pad is the only algorithm that can be said to be absolutely secure provided the pad can be exchanged reliably. That makes it ideal for certain applications.
There's so many possible formats for a one-time pad - I can't imagine a generic program that would support your CD-ROM idea.
Are you kidding? All you would need to do is save an index value somewhere. When encrypting a message, exclusive-or the message with the random data on the CD at that index value, then increment the index value by the amount of data encrypted for the next use. Vice versa when decrypting. Very simple.
Given how insecure one-time pads are, if not used carefully, and how much a PIA they are to use, if used carefully, I really don't see the point in such an addition to GPG.
You're grossly exaggerating the insecurity here. Unless you have every password you use memorized, you have some written down somewhere or stored in some device. The risk of using a one-time pad is the same, provided you've securely exchanged the pad in the first place (no big deal.)
There's no evidence they can break 3DES or Blowfish.
Yes, of course the NSA will announce when they've broken 3DES or Blowfish.
They would be able to decrypt any message they wanted to; half the time they would just feed them to a computer, the computer would run the top 50 trivial algorithms, and spit out the answer.
Yes, that works for 50 trivial algorithms. What I'm talking about is allowing novice users to create any number of trivial algoritms, and to combine any number of same together with stronger algorithms to create a truly impossible job for the NSA. It wouldn't be 50 tries they'd have to do, it'd be more like 10,000 factorial.
No, not at all.
OK, I see /. truncates messages, it's happened to my reply (first time I've seen it happen to me) and it happened to your message. I'm particularly interested in how you were going to finish the following sentence:
I would bother responding to your last comment about why PGP is "weak", but really, it's c
Again, I was making a big deal about the checksum appearing in the zip file that PGP creates before encrypting.
You don't think that's a problem?
Dude, I've read through all of Schneier's "Applied Cryptography", First Edition, and spent many an hour comparing his Second Edition with his first.
Read "Secrets and Lies" too.
I've implemented in C any number of encryption algorithms, have invented a few of my own too actually (yes I know, LOL.) I got OpenSSL to compile and work the way I wanted in both Linux and Windows environments, um, OpenSSH too. PAM. Etc.
I'm no super-duper-math-genius or anything, but then, clearly, neither are you.
I think you're just having a bad day. A lot of people here don't get the pussy they need, and I'm thinking we should elect you as our leader... you've got all the symptoms and you don't seem to mind showing it. I salute you.
But if anybody is trolling here, it is you.
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?
I'll take your word for gnupg's pluggability, since no mention seems to be made of it in the documentation... but I'll read it again.
/dev/random, make a copy, and use those 680MB to encrypt the emails they send to one another... for life. Very cool, very doable... very unbreakable.
However...
I think you miss the point regarding the value of increasing the number of algorithms. The complexity increase is not n times but rather n factorial. Algorithms can be applied in daisy-chain fashion upon other algorithms. Even a trivial algorithm works here.
Yes, a decent cryptoanalyst will tear apart a trivial algorithm, but how many decent cryptoanalysts are there? More than the number of people who can choose any combination of installed algorithms via point-and-click?
No.
Again, we've been trained to think about this as a problem of protecting a single channel. All of that is still valid, for that one specific problem. The problem of how to get the NSA to give up this travesty of a cause is quite another, and it is realizable only by demonstrating to them the impossibility of the problem they are attempting to solve.
For instance, does gnupg allow me to plug in a one-time pad as an encryption algorithm? I don't think so. The gui I'm envisioning would. Yes, there are practical considerations in the use of the one-time pad, but once those are met, the resulting communication is impervious to cryptoanalysis, regardless of the technology the NSA is wielding.
For instance, two friends at graduation who are going their separate ways, agree to rip a CD using
Get enough people doing that, along with people using the encoder rings they got in their box of Cap't Crunch, and rot13, and all the trivial extensions of all the serious encryption algorithms and the NSA will be swimming in complexity... a kind of complexity they can't easily leverage their hardware to tame.
nsa retards
are fucking with my freedom
and i pay these guys!
I know gnupg has made some very big strides in this area, but clearly, now is the time to devise a framework upon which popular encryption is allowed to survive PGP.
The point isn't whether the geeks can do it. The point is whether some poor, persecuted soul in some totalitarian country, like -- um, you know -- can click a button and send an email out of the country or to his best friend, securely.
Clearly we would like to see front-ends developed for all the popular email applications that can accept code implementing any kind of encryption scheme whatsoever, and encryption algorithms that can fit into any popular email application available.
If somebody comes up with a new encryption algorithm, they shouldn't have to write code to support Evolution, Eudora, Outlook Express, so forth and so on.
Likewise, somebody should be able to write a front-end for a email application according to a specific API and expect to see every available encryption algorithm thus far implemented available from within that email application.
And of course, it all needs to be open source. If anything needs to be open source, it is this.
gnupg is great, but it presumes a single algorithm, doesn't it? Wouldn't it be much better to make it easier to introduce new algorithms into the mix? Put yourself in the position of the GS-7 analyst sitting in Virginia who has to run all these decipher jobs. If he gets to *assume* that the encryption being used is pgp-style, his workload is modest, he just needs to feed the file to the program.
But if he first has to figure out what algorithm is being used, suddenly his job becomes many orders of magnitude harder. Especially if there are hundreds if not thousands of algorithms out there, each and every one available to the common man for his use.
I know we're not supposed to rely on obscurity for encryption, but that presumes your only interest is in protecting a single channel of communication. If your interest is in protecting *all* channels of communication, obscurity becomes viable. Something as trivial as taking the output of gnupg and exclusive-or'ing with a Erica Rose Campbell jpeg would add another - if - statement to the NSA's decryption code. Add another 100 jpegs every day and very quickly the NSA's job becomes very, very hard.
I never liked PGP. They zip before encrypting, and I could never get an answer from Zimmermann as to whether or not the checksum survived the zip. If the checksum survives, all the NSA has to do is unzip every try at an encrypted file and see if the checksums match. Strip out the checksum, and their job becomes much harder. The checksum needs to go.
That's the thing. NAI ain't selling PGP anymore.
Makes you wonder who's running NAI.
The article seems to indicate that while Xbox is placing great emphasis on networking, Playstation is not.
I have to believe the Times errs here. Sony after all owns Everquest.
Or... is it because Sony owns Everquest that they think they have network games covered?
As addictive as EQ is, it isn't a substitute for robust game network that allows for the development of many different kinds of games... or is it? Will VR worlds be the be-all-and-end-all of network gaming, even well into the future?
I think that's a risky gamble. Sony should put more resources into providing better support for more generic network games, if only because Microsoft is doing it with Xbox.
We knew TRUSTe was shit years ago, didn't we?
I guess now there is left no doubt whatsoever.
Now I'm trying to figure out how to cancel the service.
Why not let me win JUST ONCE!!!
Just send it all to me.
No way to know whether they're rude or not either, unless, like, they run you over or something.
Those Israelis who were caught running explosives probably dumped their cargo somewhere around Northern Cal, where it blew up, and triggered some kind of post-Nevada-testing-site showdown with the San Andreas Fault.
Or something like that.
Peck them to death!
Everybody should just take Sony to small claims court!
Bring your fucked-up iMac -- or buy an iMac and have it fucked up by Sony first -- and bring the iMac to small claims court, asking for Sony to fix your iMac.
If everybody did this, what would Sony do? Deploy a lawyer to every one-horse town in America defending these claims?
If they did, the cost would be exorbitant beyond belief! If they didn't, the cost would be exorbitant beyond belief!
Think small beaks. Biting hard. Lots of them.
Get all the little companies who are at risk from these filthy blood-sucking parasites to pool their resources and sue them back under the rock from whence they came.
How many businesses use web form entry? 1,000,000? If you just get 10,000 to kick in a $1000 each you'll have these dogs back to licking their balls clean in no time.
You fixed my problem!!!
The issue was that libGL.so was linked to libGL.somethingelseiforgetwhat and not libGL.so.1.
Changing that and running sax2 gives me a working desktop. KDE is beautiful.
Bless you.
I can run X too, using the dummy nv driver included with the distribution.
When I try to get the real nvidia driver to work, whether it be the one downloaded using SuSE's updater or one I download myself from Nvidia I invariably end up in 640x480 mode with a desktop the size of Kansas.
Changing window managers doesn't seem to help, at all.
I have the same problem with my Logitech Optical Mouse. And I made a big post earlier complaining about there being no info, stickers, etc., but this is easily more irritating.
Long time SuSE user here, who in the past always went with the "install everything" option.
With 8.0, there was no "install everything" option -- or I missed it -- so I picked "Default KDE w/ Office".
You'd expect that info would be installed with such an option, yes?
The reason I needed info was because SuSE is still using lilo, and I'm sorry, but grub simply rules, alpha or not, so I had to do that bit manually.
Also, I have a GeForce4 TI 4600 and I can't for the life of me get the thing to work right (yes I have the latest nVidia drivers), but I attribute that to it being a new card and all and fully expect somebody else to figure it out for me. Not a big deal since I stay in text mode most of the time anyways (use the GeForce for Windows games.)
Oh, yes, and one last thing... NO STICKERS!!! SuSE always has an assortment of somewhat-silly-but-nevertheless-cool stickers I can put on things and regret having done so later, but none were to be found in 8.0.
So sad it makes me.