I don't understand why the Creative Commons license is being singled out as vulnerable to this sort of problem. Anyone, anywhere, could buy content from one entity who claims to have a copyright on it, then get hit with a lawsuit by another entity who disputes the copyright. Creative Commons is no more and no less subject to the problem.
The largest problem w/ the proposed system is that, even though it may make the active port difficult to find, it leaves a large footprint. The open ports may be implemented as honeypots, but if you aren't using the standard tcp stack library it doesn't inconvenience the attacker but instead tells him the target exists. Any vulnerability in the implementation can then be exploited.
I have an alternative proposal. Have a udp or icmp service where, before connecting to a tcp server port, a client must send a packet containing the destination port along with a 32-bit entry code. (This entry code could be, for instance, the first 4 bytes of the SHA1 of a concatenation of a private key plus the client's IP.) Without receiving this packet the server's port would return no data on the attempted initiation of a connection, resulting in a "stealthed" server port.
Wikipedia has the potential to hold everything, but that may not be wise. Should Wikipedia's articles about books also hold copies of the books, even if they are in the public domain? It would be easy enough to do. Alternatively it could link directly to the book in the Gutenberg Project archives. As an encyclopedia Wikipedia should contain useful information about subjects, but not necessarily the entire subject.
It's the usual. Legislators listen to lobbyists, at least until their constituents protest their heads off. Then they'll bother to read the actual bill.
So... Let's say I went and picked up a bargain 1st generation iPhone once the 3G version emerged. I don't mind slower speeds, so long as I get service. Will EDGE be going away? Will I still have that service?
Okay, I understand the attack now, but I don't see how an attacker can utilize this bug without access to the output of the decryption of the "poisoned" message. Given such access, the attacker doesn't need to use such an exploit, he already knows what is on the target's computer.
Sorry, I was looking at this the wrong way. The "math error" Mr. Shamir must be talking about, with regard to "chips", must be an error in the logic system in an arithmetic logic unit. An error that might, for instance, cause one or more bits in a register to stick in one state or another, would indeed affect future messages, disrupting PRNG (both encryption algorithms and one-way) and public-key computations. I doubt a system so badly affected could continue to operate for very long, but an attacker who monitors outgoing messages after sending that "poisoned" message to trigger such an error would learn valuable clues to the machine's cryptosystem and keys, perhaps enough to trivialize breaking its keys.
Depending on what sort of application the user's machine performs, I can think of a few ways, offhand, to help guard against this sort of attack. A simple self-test prior to encrypting each message might work but might be onerous with a heavily-utilized system. Reducing the number of registers used for encryption might help, surprisingly, because any error would tend to cascade more quickly, reducing the output to a complete mess rather than something analyzable. Also, where practical, decrypting part of the message after encryption would work as a fast check for this sort of corruption.
I'm not sure how Mr. Shamir envisions a simple "math error" causing a problem. A buffer overflow exploit, perhaps, but not a math error... A user on a flawed but protected computer receives a "poisoned" encrypted message, opens it... And what happens? The math error, say, elicits some aspects of the user's private key in the decoded message; but how does the attacker then obtain that information without already having access to the machine? Further outgoing messages wouldn't have any usable information, no modern cryptosystem allows a received message from affecting any such message; a code exploit might affect the system's PRNG, but a math error shouldn't feed back to the PRNG unless it was horribly implemented. Without something affecting the user's machine's code execution, I can't see any way for an attacker to utilize a math error in a decryption function.
Makes me wonder if they'll be able to throw you in an MRI without removing your metallic objects. Or even a Terminator-style MRI-based walk-through security scanner?
Maybe Facebook has fifty million USERS. It's true most of them wouldn't care about Google's new API; most of them won't be writing a lick of code. They'll certainly be willing to incorporate pre-made widgets into their pages, though, which makes the question whether Google's API will produce neater widgets than Facebook's proprietary one.
I doubt Microsoft would allow Dell etc to pare their Vista install down, or change its component structure to move portions to a separate drive, just so it could boot on a flash drive.
...if it weren't for Vista's size, we'd see the boutique computer manufacturers like Dell making machines w/ 16 GB flash boot drives for "super-fast" machines as default. As it is, we'll have to wait until at least 64 GB drives are reasonably priced for this to happen.
Slashdot Mirror
BitTorrent would work very well to distribute this information.
WikiBudget.com
I don't understand why the Creative Commons license is being singled out as vulnerable to this sort of problem. Anyone, anywhere, could buy content from one entity who claims to have a copyright on it, then get hit with a lawsuit by another entity who disputes the copyright. Creative Commons is no more and no less subject to the problem.
The largest problem w/ the proposed system is that, even though it may make the active port difficult to find, it leaves a large footprint. The open ports may be implemented as honeypots, but if you aren't using the standard tcp stack library it doesn't inconvenience the attacker but instead tells him the target exists. Any vulnerability in the implementation can then be exploited.
I have an alternative proposal. Have a udp or icmp service where, before connecting to a tcp server port, a client must send a packet containing the destination port along with a 32-bit entry code. (This entry code could be, for instance, the first 4 bytes of the SHA1 of a concatenation of a private key plus the client's IP.) Without receiving this packet the server's port would return no data on the attempted initiation of a connection, resulting in a "stealthed" server port.
Chicken chicken chicken: Chicken chicken. Chicken!
Wikipedia has the potential to hold everything, but that may not be wise. Should Wikipedia's articles about books also hold copies of the books, even if they are in the public domain? It would be easy enough to do. Alternatively it could link directly to the book in the Gutenberg Project archives. As an encyclopedia Wikipedia should contain useful information about subjects, but not necessarily the entire subject.
Redundant, flamebait... The mods here need to watch more movies. :-P
You know it's not a real country anyway.
It's the usual. Legislators listen to lobbyists, at least until their constituents protest their heads off. Then they'll bother to read the actual bill.
So... Let's say I went and picked up a bargain 1st generation iPhone once the 3G version emerged. I don't mind slower speeds, so long as I get service. Will EDGE be going away? Will I still have that service?
:-)
Yeah... But it'll want about three-fitty.
Okay, I understand the attack now, but I don't see how an attacker can utilize this bug without access to the output of the decryption of the "poisoned" message. Given such access, the attacker doesn't need to use such an exploit, he already knows what is on the target's computer.
But the point I was trying to make was, how would the attacker retrieve that information?
Sorry, I was looking at this the wrong way. The "math error" Mr. Shamir must be talking about, with regard to "chips", must be an error in the logic system in an arithmetic logic unit. An error that might, for instance, cause one or more bits in a register to stick in one state or another, would indeed affect future messages, disrupting PRNG (both encryption algorithms and one-way) and public-key computations. I doubt a system so badly affected could continue to operate for very long, but an attacker who monitors outgoing messages after sending that "poisoned" message to trigger such an error would learn valuable clues to the machine's cryptosystem and keys, perhaps enough to trivialize breaking its keys.
Depending on what sort of application the user's machine performs, I can think of a few ways, offhand, to help guard against this sort of attack. A simple self-test prior to encrypting each message might work but might be onerous with a heavily-utilized system. Reducing the number of registers used for encryption might help, surprisingly, because any error would tend to cascade more quickly, reducing the output to a complete mess rather than something analyzable. Also, where practical, decrypting part of the message after encryption would work as a fast check for this sort of corruption.
I'm not sure how Mr. Shamir envisions a simple "math error" causing a problem. A buffer overflow exploit, perhaps, but not a math error... A user on a flawed but protected computer receives a "poisoned" encrypted message, opens it... And what happens? The math error, say, elicits some aspects of the user's private key in the decoded message; but how does the attacker then obtain that information without already having access to the machine? Further outgoing messages wouldn't have any usable information, no modern cryptosystem allows a received message from affecting any such message; a code exploit might affect the system's PRNG, but a math error shouldn't feed back to the PRNG unless it was horribly implemented. Without something affecting the user's machine's code execution, I can't see any way for an attacker to utilize a math error in a decryption function.
Er, delete the second "don't". Sorry. X_X
...and I don't think journals should accept papers which don't include proofs verifiable only with closed-source software.
BitTorrent download
...because this isn't a troll.
http://www.rockwellcollins.com/news/page8813.html
Clicky for bigness.
Makes me wonder if they'll be able to throw you in an MRI without removing your metallic objects. Or even a Terminator-style MRI-based walk-through security scanner?
Maybe Facebook has fifty million USERS. It's true most of them wouldn't care about Google's new API; most of them won't be writing a lick of code. They'll certainly be willing to incorporate pre-made widgets into their pages, though, which makes the question whether Google's API will produce neater widgets than Facebook's proprietary one.
I doubt Microsoft would allow Dell etc to pare their Vista install down, or change its component structure to move portions to a separate drive, just so it could boot on a flash drive.
...if it weren't for Vista's size, we'd see the boutique computer manufacturers like Dell making machines w/ 16 GB flash boot drives for "super-fast" machines as default. As it is, we'll have to wait until at least 64 GB drives are reasonably priced for this to happen.