He posited three theories and gave his assessment of their relative likelihoods. The worst that could possibly happen to him is that his assessment was wrong.
Basically they say that if the Bible says "the Earth is flat" and then someone proves that it isn't, then the Bible was wrong.
Umm. You are talking about a religion which believes that the capybara, the largest rodent in the world, is actually a fish.
So, yeah. I'd say the Catholic church is able to "redefine" itself as necessary. If by that you mean, redefine reality so that they can eat meat on Fridays...
Hey, and I was just wondering WTF to do this weekend... Maybe I'll stop by the booth. What type of beer are you using in the kraut? I usually just use the beer I previously boiled the sausages in. You get that meaty, fatty flavor along with a bit of cracked red pepper. I typically use something cheap and amber in color or darker.
I'll be the guy hanging out with a bunch of Russians:-)
I urge you to put in the effort, and make the distinction between site-wide bias, and the bias of particular individuals. Yes, Slashdot as a whole is very biased against Microsoft. But individual Slashdotters must be judged on a case-by-case basis.
It's pointless to whine about the bias. It's like standing on a Florida beachfront screaming at the hurricane to "Turn back!"
Either this is not true or we would have global cooling as a result of this. You cannot fool physics.
You're misunderstanding the cycle of energy in the atmosphere. Only some of the energy in the atmosphere is stored as heat. The rest is in the kinetic energy of convection and wind. Extracting wind energy decreases (for the most part) the kinetic portion of this energy. So the air doesn't cool down, it just moves slower.
Also, "energy forcing" means the cycling of energy through the atmosphere by rising temperatures due to global warming. The point being made was that, if we switched from petro-energy over to wind energy, the amount of energy being extracted from the atmosphere would make up for the additional energy being cycled through it ("forced") by the greenhouse effect.
Basically, the point is that the effects wrought by global warming occur mostly in the atmopshere. Thus, the logical point to counteract those changes is in the atmosphere. By switching from petro-energy to wind we are, in a way, dealing with both problems simultaneously. We get energy and counteract the effects of CO2 in the atmosphere. Of course this is all theoretical because no wind facilities of a large enough scale to test it have been constructed.
The only problem with this ( it's not much of one ) is that at small key sizes, it means that if you choose to bruteforce the key, you have a much better chance of telling which decryption result is the genuine original plaintext, much like randomly trying wep keys until the IP checksum is correct.
The thing is, if you decrypt with an incorrect key, the result looks like random data. So it's easy to tell whether you've found the plaintext by looking to see how random the data is. A simple mutual information test can quickly tell you if there is any kind of organization to the data.
Of course, if the plaintext is actually random data, or something close to it (like compressed data), this trick won't help you. But the point is, there are other ways to tell if you've decrypted with the correct key besides validating a checksum. So I don't consider it to be a particular weakness.
You could just collect the static charge that wind generates (that's where lightning gets its energy).
This has already been done. You have two electrodes. One electrode is annular (ring-shaped) and is held at a high voltage. Water is blasted at high speed through the hole in this "donut" electrode. As the water jet breaks up into droplets, these droplets acquire electrical charge by induction. Then, the force of wind carries these charged droplets to a large, wire-mesh collection grid/electrode. This can generate potentials of millions of volts (but extremely small currents). Very large scale implementations of this device are possible.
It's the same basic idea behind Kelvin's Thunderstorm, which uses gravity instead of wind to seperate the charged water droplets.
For this idea to work, however, you need high wind speeds. The energy in this device comes from the wind. The wind must be forceful enough to push the water droplet away from the annular electrode (to which it is being attracted) onto the wire mesh.
Wind tubines have the advantage because they can work well in extremely low winds.
See, it's all well and good to extract the energy from the atmosphere, but you're just storing the energy for later. As soon as you use it, it ends up as heat.
So use the energy to power a gigantic array of efficient lasers and shoot it off into space. Come on, this should be obvious.
Are you saying that you never need to patch Linux?
I believe what he was saying is that, for him at least, a Linux system for his mother would be easier to administer and update remotely than a Windows system.
You Windows people are really frothing at the mouth these days... (As are quite a few Linux zealots.) Chill.
But that question has nothing to do with XOR, does it?
My point was simply that XOR is a key-combining operation. The fact that an algorithm uses XOR does not imply insecurity. There are, of course, plenty of bone-headed possible implementations. But none of those problems are the fault of the XOR operation.
So, what planet is this 40-mile line of sight transmission designed for?
Don't be cynical. I can look out my office window and see a mountain which is 65 miles away from here. The world is not a "totally flat plain or ocean."
Do you live in the Midwest or something? The entire world isn't all like that, you know!
What you are stating is completely orthogonal to XOR.
There are ineffective ways to use a gun, too. Loading it with blanks, as one example, would make it particularly ineffective for its intended purpose. It's not the gun's fault, however.
My point, which I have stated repeatedly and few seem to grasp, is that there is no inherent weakness in the use of XOR for encryption. It is the framework of the surrounding cryptosystem which will either make or break XOR as an effective key-combining function.
Show me where the "dig" was. For the life of me, I don't know what you're talking about. Unless you're referring to my comment that "Windows thrashes." That's a fact. Stating a fact, last time I checked, is not a "dig."
Your comment certainly applies to all OSes even though you applied it to Windows only.
The OP was referring to a Windows system. I continued the thread of discussion from where it left off. I think you're hallucinating things, buddy.
Now, to answer your question, which was legitimate despite your asinine attitude, no, Linux does not require a swap file. And yes, a Linux swap file/partition is equally vulnerable to this, if you don't encrypt it. However, it's easy to use the cryptoloop driver to have an encrypted swap partition.
Is that possible under Windows? I see no technical reason why it couldn't be done. I'm not aware of a product which does it.
Now quit smoking that damiana, or whatever else is making you so fucking paranoid.
Yes. There are many different ways to convert a password into a key for the particular cipher you are using. As always in cryptography, there are both good and bad ways to do it.
One-Time pad means ONE-TIME ! If you use it twice, the security becomes exactly Zero.
Yes, but the problem is using the pad again. Nothing to do with XOR. Notice that any key-combining operation must be a bijective operation (i.e., "one to one, and onto"). Thus, at least theoretically, you can determine the key by comparing various plain/ciphertext pairs, regardless of which key-combining operation was chosen. Yes, XOR makes this slightly easier. So?
XOR is not the problem. The fact that the key is reused, and is most likely much shorter than the plaintext, is the problem.
Anything you drop into the virtual drive becomes encrypted.
No problem. I'll just grep through your swap file. The data might be secure on the encrypted volume, but it isn't encrypted in memory. If your system thrashes, as all Windows systems do, then chances are your "secure" information is there in unencrypted form in your swap file.
The password doesn't have to be stored, in hashed form or otherwise.
Instead of hashing the PASSWORD, you can hash the DATA. If you decrypt with the wrong key, the hash of the corrupted data will certainly not match the corrupted hash of the original data. Maybe that isn't clear. Let me try again.
Suppose you have data D and the hash of that data, H(D). Now, encrypt them with key A:
Ciphertext = Encrypt_A(D . H(D))
Then,decrypt with incorrect key B:
Plaintext_Incorrect = Decrypt_B(Ciphertext) = C . GarbageHash.
Now, since the incorrect key will produce garbage instead of meaningful data, we know that H(C) != GarbageHash if the key is incorrect. Thus, you can verify whether the key was correct without storing the key, or a hash of the key, anywhere.
Although what these guys did is unpardonable. I mean XOR? Jeez.
What's wrong with XOR? Example. I've encrypted a short message of ten bytes, by XORing it with a random sequence of ten bytes. Here's the ciphertext:
26 6B F1 2C 2E 1E 71 12 A9 68
Since XOR encryption is so weak, this should be no sweat to crack, right?
Unfortunately, you'll never be able to crack it, because you don't know what the key was. Even if you found a key that would decrypt this sequence to a meaningful series of bytes, you still don't know if that's the correct answer. More than one valid message can fit into 10 bytes, and you have no way of telling which one of those valid messages was the one I intended. It is literally unbreakable. This is called a one-time pad. Now, if I used the same key repeatedly to encrypt lots and lots of data, you could apply statistical techniques to attack it. But the weakness is not inherent in the XOR operation.
The weakness is in the key security. If you cannot protect the key properly, not even the most complicated cipher in the world can help you.
XOR is a perfectly legitimate method for combining the key, or key-generated data, with the plaintext.
If the attacker had a good sample of passwords, this would be vulnerable to statistical analysis attacks.
Not if the key was exactly as long as the message. In that case, we'd have a system equivalent to a one-time pad (i.e., unbreakable) so long as the key was kept secure.
In this case, it might be feasible to XOR an 8-character password with 8 random bytes (those 8 random bytes would be the key). The problem isn't the XOR operation. The problem is maintaining the security of the key itself.
Statistical attacks can only work when there is a lot of ciphertext, AND the key is significantly shorter than the message.
In zero-G, a barf bag wouldn't be quite so useful. In a normal airplane, if you puke, the vomit falls due to gravity into the barf bag.
In a zero-G flight, if you vomited, gravity would not pull the vomit into the bag. Instead, the vomit would float around the cabin.
Unless of course you vomited forcefully, a.k.a. projectile vomit, in which case you could carefully aim and possibly vomit into the bag from ten feet away!
Slashdot Mirror
At no point did he state "Intel lied about this."
I think you're overly paranoid.
It means having two monitors, you sadly ignorant twit...
Umm. You are talking about a religion which believes that the capybara, the largest rodent in the world, is actually a fish.
So, yeah. I'd say the Catholic church is able to "redefine" itself as necessary. If by that you mean, redefine reality so that they can eat meat on Fridays...
I'll be the guy hanging out with a bunch of Russians :-)
I agree, but you should at least mention the cost -- at least $6 a bottle around here at least.
I urge you to put in the effort, and make the distinction between site-wide bias, and the bias of particular individuals. Yes, Slashdot as a whole is very biased against Microsoft. But individual Slashdotters must be judged on a case-by-case basis.
It's pointless to whine about the bias. It's like standing on a Florida beachfront screaming at the hurricane to "Turn back!"
You're misunderstanding the cycle of energy in the atmosphere. Only some of the energy in the atmosphere is stored as heat. The rest is in the kinetic energy of convection and wind. Extracting wind energy decreases (for the most part) the kinetic portion of this energy. So the air doesn't cool down, it just moves slower.
Also, "energy forcing" means the cycling of energy through the atmosphere by rising temperatures due to global warming. The point being made was that, if we switched from petro-energy over to wind energy, the amount of energy being extracted from the atmosphere would make up for the additional energy being cycled through it ("forced") by the greenhouse effect.
Basically, the point is that the effects wrought by global warming occur mostly in the atmopshere. Thus, the logical point to counteract those changes is in the atmosphere. By switching from petro-energy to wind we are, in a way, dealing with both problems simultaneously. We get energy and counteract the effects of CO2 in the atmosphere. Of course this is all theoretical because no wind facilities of a large enough scale to test it have been constructed.
The thing is, if you decrypt with an incorrect key, the result looks like random data. So it's easy to tell whether you've found the plaintext by looking to see how random the data is. A simple mutual information test can quickly tell you if there is any kind of organization to the data.
Of course, if the plaintext is actually random data, or something close to it (like compressed data), this trick won't help you. But the point is, there are other ways to tell if you've decrypted with the correct key besides validating a checksum. So I don't consider it to be a particular weakness.
This has already been done. You have two electrodes. One electrode is annular (ring-shaped) and is held at a high voltage. Water is blasted at high speed through the hole in this "donut" electrode. As the water jet breaks up into droplets, these droplets acquire electrical charge by induction. Then, the force of wind carries these charged droplets to a large, wire-mesh collection grid/electrode. This can generate potentials of millions of volts (but extremely small currents). Very large scale implementations of this device are possible.
It's the same basic idea behind Kelvin's Thunderstorm, which uses gravity instead of wind to seperate the charged water droplets.
For this idea to work, however, you need high wind speeds. The energy in this device comes from the wind. The wind must be forceful enough to push the water droplet away from the annular electrode (to which it is being attracted) onto the wire mesh.
Wind tubines have the advantage because they can work well in extremely low winds.
So use the energy to power a gigantic array of efficient lasers and shoot it off into space. Come on, this should be obvious.
I believe what he was saying is that, for him at least, a Linux system for his mother would be easier to administer and update remotely than a Windows system.
You Windows people are really frothing at the mouth these days... (As are quite a few Linux zealots.) Chill.
But that question has nothing to do with XOR, does it?
My point was simply that XOR is a key-combining operation. The fact that an algorithm uses XOR does not imply insecurity. There are, of course, plenty of bone-headed possible implementations. But none of those problems are the fault of the XOR operation.
Don't be cynical. I can look out my office window and see a mountain which is 65 miles away from here. The world is not a "totally flat plain or ocean."
Do you live in the Midwest or something? The entire world isn't all like that, you know!
God, does anyone even know what I'm talking about?
There are ineffective ways to use a gun, too. Loading it with blanks, as one example, would make it particularly ineffective for its intended purpose. It's not the gun's fault, however.
My point, which I have stated repeatedly and few seem to grasp, is that there is no inherent weakness in the use of XOR for encryption. It is the framework of the surrounding cryptosystem which will either make or break XOR as an effective key-combining function.
Where did I mention Linux?
Why the stupid pointless dig at Windows?
Show me where the "dig" was. For the life of me, I don't know what you're talking about. Unless you're referring to my comment that "Windows thrashes." That's a fact. Stating a fact, last time I checked, is not a "dig."
Your comment certainly applies to all OSes even though you applied it to Windows only.
The OP was referring to a Windows system. I continued the thread of discussion from where it left off. I think you're hallucinating things, buddy.
Now, to answer your question, which was legitimate despite your asinine attitude, no, Linux does not require a swap file. And yes, a Linux swap file/partition is equally vulnerable to this, if you don't encrypt it. However, it's easy to use the cryptoloop driver to have an encrypted swap partition.
Is that possible under Windows? I see no technical reason why it couldn't be done. I'm not aware of a product which does it.
Now quit smoking that damiana, or whatever else is making you so fucking paranoid.
Yes. There are many different ways to convert a password into a key for the particular cipher you are using. As always in cryptography, there are both good and bad ways to do it.
The weakness comes from a braindead implementation, not XOR.
Yes, but the problem is using the pad again. Nothing to do with XOR. Notice that any key-combining operation must be a bijective operation (i.e., "one to one, and onto"). Thus, at least theoretically, you can determine the key by comparing various plain/ciphertext pairs, regardless of which key-combining operation was chosen. Yes, XOR makes this slightly easier. So?
XOR is not the problem. The fact that the key is reused, and is most likely much shorter than the plaintext, is the problem.
No problem. I'll just grep through your swap file. The data might be secure on the encrypted volume, but it isn't encrypted in memory. If your system thrashes, as all Windows systems do, then chances are your "secure" information is there in unencrypted form in your swap file.
Instead of hashing the PASSWORD, you can hash the DATA. If you decrypt with the wrong key, the hash of the corrupted data will certainly not match the corrupted hash of the original data. Maybe that isn't clear. Let me try again.
Suppose you have data D and the hash of that data, H(D). Now, encrypt them with key A:
Ciphertext = Encrypt_A(D . H(D))
Then ,decrypt with incorrect key B:
Plaintext_Incorrect = Decrypt_B(Ciphertext) = C . GarbageHash.
Now, since the incorrect key will produce garbage instead of meaningful data, we know that H(C) != GarbageHash if the key is incorrect. Thus, you can verify whether the key was correct without storing the key, or a hash of the key, anywhere.
Right, but the weakness is that B IS CONSTANT, not the fact that we're using XOR. Sheesh.
What's wrong with XOR? Example. I've encrypted a short message of ten bytes, by XORing it with a random sequence of ten bytes. Here's the ciphertext:
26 6B F1 2C 2E 1E 71 12 A9 68
Since XOR encryption is so weak, this should be no sweat to crack, right?
Unfortunately, you'll never be able to crack it, because you don't know what the key was. Even if you found a key that would decrypt this sequence to a meaningful series of bytes, you still don't know if that's the correct answer. More than one valid message can fit into 10 bytes, and you have no way of telling which one of those valid messages was the one I intended. It is literally unbreakable. This is called a one-time pad. Now, if I used the same key repeatedly to encrypt lots and lots of data, you could apply statistical techniques to attack it. But the weakness is not inherent in the XOR operation.
The weakness is in the key security. If you cannot protect the key properly, not even the most complicated cipher in the world can help you.
XOR is a perfectly legitimate method for combining the key, or key-generated data, with the plaintext.
Not if the key was exactly as long as the message. In that case, we'd have a system equivalent to a one-time pad (i.e., unbreakable) so long as the key was kept secure.
In this case, it might be feasible to XOR an 8-character password with 8 random bytes (those 8 random bytes would be the key). The problem isn't the XOR operation. The problem is maintaining the security of the key itself.
Statistical attacks can only work when there is a lot of ciphertext, AND the key is significantly shorter than the message.
In a zero-G flight, if you vomited, gravity would not pull the vomit into the bag. Instead, the vomit would float around the cabin.
Unless of course you vomited forcefully, a.k.a. projectile vomit, in which case you could carefully aim and possibly vomit into the bag from ten feet away!
I detect a new Olympic sport in the making...