If they're clever enough, that won't even work in theory. The ransom virus can just make up a symmetric key for the user in question, encrypting everything with this symmetric key, and the key itself with PK crypto. The extortionist asks for the encrypted symmetric key and gives the decrypted symmetric key in return, and there you are, none the wiser as to what the private component of the PK crypto scheme is.
This sounds like a straightforward implementation of cryptoviral extortion. Hopefully, the authors made some stupid mistake (like using the same key everywhere, or encrypting the data directly instead of doing it indirectly through a symmetric crypto key).
Still, the basic strategy remains viable, so the best opposing strategy would be to harden systems. Unix permissions won't help you here, since you usually have rights to write or alter permissions to stuff in your home directory. Backups would work (but only if you didn't change anything after the last backup), and so would default sandboxing/fine-grained security, or just not running suspicious apps (which amounts to a sort of "whitelist based security" where whatever not on the list gets zero privileges).
Intelligence is a tool - it's the tool for devising workable plans (and adapting them to changing conditions). Consider chess engines on the one hand and intelligence tests on the other.
The problem with AI, as it's popularly seen, is that the term has been overloaded so much, to the point of "intelligence is whatever we are". We are conscious, therefore "good AIs" should be conscious; we have wishes that provide the input to our plans, therefore, so should an AI; we don't like others, hence AIs-as-Terminators, and so on. This is not to say that making an artificial consciousness (or artificial emotion engine, or whatever) aren't interesting tasks, but they aren't within the AI proper, except to the extent wherein these are subordinate to a greater plan.
Seeing it this way, the "optimal" AI would be something like a polytime PSPACE-solver. Such a beast doesn't exist (and probably never will), but it gives a bound to the concept.
I'm very curious how Obama feels he can do about increasing the participation of third parties in the US political system.
STV for the House, round robin (Condorcet) for the Presidency, either for the two Senators from each state.
Of course, the real question is not whether he can, but whether he would. As mentioned in another post, what incentive does a politician from a major party have in introducing further competition?
They'd probably make a VM where you can only move the ingame cursor by using the keyboard. Then the users start complaining about why they can't use the mouse, and they reply by saying that to add the code would invite a maintenance nightmare. Then someone produces a patch, but they say they won't implement it, and in any case, they like keyboard-only ingame cursors, so what's the fuss? We're doing this for ourselves, man! Love it or leave it!
It may be too late for you now (though you can downgrade by manually getting the packages, uninstalling the new ones, and then dpkg -i each in turn), but if you go back to Gutsy Gibbon, put something like this in your apt preferences file:
Explanation: Part of GAIM, newer versions unusable
Package: pidgin libpurple0 libpurple-bin pidgin-data
Pin: version 2.3.1*
Pin-Priority: 1001
Watch out when you do dist upgrades, I might have missed a few packages, because when I try to do a dist-upgrade on my Debian, it says it's going to delete pidgin (since it can't upgrade it).
"I am not the first to point out that capitalism, having defeated Communism, now seems about to do the same to democracy. The market is doing splendidly, yet we are not, somehow." - Ian Frazier.
No, because without a password, most password authenticated key exchange algorithm have the same security properties as Diffie-Hellman. In other words, even if you knew the password, you couldn't snoop the connection passively. The only way to thwart it is by an active attack, but for that you need the password, otherwise the two parties' keys won't match.
See SPEKE, for instance, which is pretty much a Diffie-Hellman key exchange with the (fixed) generator constant replaced by a hash of the password. Snooping SPEKE only gives the adversary g^a mod p and g^b mod p (as well as the combinations as in ordinary DH), where a and b are secret and p is known. That does no good in finding g (the hash of the password) unless the adversary can break the discrete logarithm problem, in which case you've got bigger problems on your hands.
You open up to read email. Your PC looks up mail.yourhost.com
DNS returns the IP of the Evil Impersonator.
You connect to the Evil Impersonator and start the protocol.
Evil Impersonator runs PAKE protocol in question, impersonating mail.yourhost.com, based on a guess of your password.
Your client says "incorrect password". You try a few more times and get really suspicious.
Because the PAKE protocol is a key exchange, the evil impersonator learns nothing unless he guessed the right password. Because it uses a preshared secret (the password itself), he can't MITM unless he guessed the right password, either.
Attack fails.
At this point, old inertia hits me on the head (can't change the protocols because everyone's using the old ones), but the point is that online password authentication is essentially solved. The rest is an engineering problem:)
Not in general. Straightforward "execute what you want" buffer overruns can be thwarted by using no-execute; however, this doesn't stop the overrun from overwriting data so that the right functions will have the wrong input and thus do what the exploit writer wants. So-called return-to-libc attacks (where the exploit writer rearranges the stack so that it calls prexisting functions with interesting parameters) can be made very hard to pull off with address space randomization, but that doesn't help on architectures with 32-bit or lesser size pointers.
Radical virtualization might mitigate the effects so that the bugs are irrelevant (as would a capabilities based system where, even if you do smash the stack, there's nothing interesting you can do with the privileges gained), but that's not stopping the buffer overruns themselves, just making them moot.
There's another option in practice: assume developers make bugs, find and use a buffer overflow, and then inject code that dumps the entire game. In theory, there will be no bugs and so you can't get at the content (which is bottled up inside sealed storage), but in practice... have you ever heard of a bug-free program?
That won't work with multiplayer any more than fake CD keys will, but that's nothing new. I can't say I like the way the corporations are trying to make general purpose PCs into special-purpose appliances, though; it feels too much like "Right to Read".
At which point some clever individual finds a new variety that circumvents such attacks.
Thinking a moment about it, I could envision (for instance) a peer-to-peer system that uses rateless codes along with a protocol on top of UDP, and an anonymous DHT. It wouldn't be BitTorrent anymore, but it could work like this: The one who wants files sends his IP through the anonymous DHT. Those with files transmit a nonce to that IP, and the requesting person replies (so as to prove he's giving the right IP). Then the senders transmit packets as given by a rateless erasure code encoding of the original file, and mark the packets with a fake source IP address. This works because erasure codes don't need any regular ACK-type feedback. Now add something like EigenTrust (or a robust variant of it) on top of the DHT to get rid of fake file uploads, and proof the erasure code against the case where some "senders" just pretend to have the file and send noise instead (there's a paper of how to do this, but I can't remember its title at the moment), and you're all set.
In the worst case, ISPs would implement egress filtering. That, itself, isn't a bad thing (as it prevents reflection denial-of-service attacks), and so in either case we win. And that was just a first stab; clever people could probably find some way of masquerading it as HTTPS, use secret sharing to say "but I wasn't really sharing the file, just a part of it", or whatever.
To make it economical, you'd need something more exotic -- a mass drive throwing bits of asteroid, or a high performance solar-electric ion drive, for example.
I believe their reasoning is that most games are sold the first few days and that adding these schemes slow down the pirates, thus making more people buy the game when they see the alternative is having to wait until the crack is done.
But what EA and their ilk may gain through delaying pirates this way, they lose by the schemes being so convoluted and impractical that legitimate customers purposefully search for the pirated copy so they can play something that's Better Than Original.
You can't see it because the tracker is slashdotted, but someone did submit a patch. The developers effectively said "No, it's going to be too much trouble checking all the additional cases, so forget it". He then went and made a plugin instead, and asked the developers if they could include it in the default install. Again they said no, but I don't remember for what reason. After all of this, another person (ConnorBehan) forked the code. Extreme reaction? Perhaps, but they didn't see any other option.
(Check the tracker when it goes back up, and you'll get the details.)
Slashdot Mirror
If they're clever enough, that won't even work in theory. The ransom virus can just make up a symmetric key for the user in question, encrypting everything with this symmetric key, and the key itself with PK crypto. The extortionist asks for the encrypted symmetric key and gives the decrypted symmetric key in return, and there you are, none the wiser as to what the private component of the PK crypto scheme is.
This sounds like a straightforward implementation of cryptoviral extortion. Hopefully, the authors made some stupid mistake (like using the same key everywhere, or encrypting the data directly instead of doing it indirectly through a symmetric crypto key).
Still, the basic strategy remains viable, so the best opposing strategy would be to harden systems. Unix permissions won't help you here, since you usually have rights to write or alter permissions to stuff in your home directory. Backups would work (but only if you didn't change anything after the last backup), and so would default sandboxing/fine-grained security, or just not running suspicious apps (which amounts to a sort of "whitelist based security" where whatever not on the list gets zero privileges).
Intermediate term fix: Tunnel everything over IPsec. If ISPs are going to act like Eve or Mallory, let's treat them as such.
Zombies that actually shamble.
Intelligence is a tool - it's the tool for devising workable plans (and adapting them to changing conditions). Consider chess engines on the one hand and intelligence tests on the other.
The problem with AI, as it's popularly seen, is that the term has been overloaded so much, to the point of "intelligence is whatever we are". We are conscious, therefore "good AIs" should be conscious; we have wishes that provide the input to our plans, therefore, so should an AI; we don't like others, hence AIs-as-Terminators, and so on. This is not to say that making an artificial consciousness (or artificial emotion engine, or whatever) aren't interesting tasks, but they aren't within the AI proper, except to the extent wherein these are subordinate to a greater plan.
Seeing it this way, the "optimal" AI would be something like a polytime PSPACE-solver. Such a beast doesn't exist (and probably never will), but it gives a bound to the concept.
I'm very curious how Obama feels he can do about increasing the participation of third parties in the US political system.
STV for the House, round robin (Condorcet) for the Presidency, either for the two Senators from each state.
Of course, the real question is not whether he can, but whether he would. As mentioned in another post, what incentive does a politician from a major party have in introducing further competition?
They'd probably make a VM where you can only move the ingame cursor by using the keyboard. Then the users start complaining about why they can't use the mouse, and they reply by saying that to add the code would invite a maintenance nightmare. Then someone produces a patch, but they say they won't implement it, and in any case, they like keyboard-only ingame cursors, so what's the fuss? We're doing this for ourselves, man! Love it or leave it!
It may be too late for you now (though you can downgrade by manually getting the packages, uninstalling the new ones, and then dpkg -i each in turn), but if you go back to Gutsy Gibbon, put something like this in your apt preferences file:
Explanation: Part of GAIM, newer versions unusable
Package: pidgin libpurple0 libpurple-bin pidgin-data
Pin: version 2.3.1*
Pin-Priority: 1001
Watch out when you do dist upgrades, I might have missed a few packages, because when I try to do a dist-upgrade on my Debian, it says it's going to delete pidgin (since it can't upgrade it).
How about Dubcek's Czechoslovakia? The Soviets thought it was too free to tolerate, at least, and crushed it with military might.
"I am not the first to point out that capitalism, having defeated Communism, now seems about to do the same to democracy. The market is doing splendidly, yet we are not, somehow." - Ian Frazier.
No, because without a password, most password authenticated key exchange algorithm have the same security properties as Diffie-Hellman. In other words, even if you knew the password, you couldn't snoop the connection passively. The only way to thwart it is by an active attack, but for that you need the password, otherwise the two parties' keys won't match.
See SPEKE, for instance, which is pretty much a Diffie-Hellman key exchange with the (fixed) generator constant replaced by a hash of the password. Snooping SPEKE only gives the adversary g^a mod p and g^b mod p (as well as the combinations as in ordinary DH), where a and b are secret and p is known. That does no good in finding g (the hash of the password) unless the adversary can break the discrete logarithm problem, in which case you've got bigger problems on your hands.
At this point, old inertia hits me on the head (can't change the protocols because everyone's using the old ones), but the point is that online password authentication is essentially solved. The rest is an engineering problem
Not in general. Straightforward "execute what you want" buffer overruns can be thwarted by using no-execute; however, this doesn't stop the overrun from overwriting data so that the right functions will have the wrong input and thus do what the exploit writer wants. So-called return-to-libc attacks (where the exploit writer rearranges the stack so that it calls prexisting functions with interesting parameters) can be made very hard to pull off with address space randomization, but that doesn't help on architectures with 32-bit or lesser size pointers.
Radical virtualization might mitigate the effects so that the bugs are irrelevant (as would a capabilities based system where, even if you do smash the stack, there's nothing interesting you can do with the privileges gained), but that's not stopping the buffer overruns themselves, just making them moot.
There's another option in practice: assume developers make bugs, find and use a buffer overflow, and then inject code that dumps the entire game. In theory, there will be no bugs and so you can't get at the content (which is bottled up inside sealed storage), but in practice... have you ever heard of a bug-free program?
That won't work with multiplayer any more than fake CD keys will, but that's nothing new. I can't say I like the way the corporations are trying to make general purpose PCs into special-purpose appliances, though; it feels too much like "Right to Read".
Jason Nesmith: Did I just hear that the animal turned inside out, and then it EXPLODED?
At which point some clever individual finds a new variety that circumvents such attacks.
Thinking a moment about it, I could envision (for instance) a peer-to-peer system that uses rateless codes along with a protocol on top of UDP, and an anonymous DHT. It wouldn't be BitTorrent anymore, but it could work like this: The one who wants files sends his IP through the anonymous DHT. Those with files transmit a nonce to that IP, and the requesting person replies (so as to prove he's giving the right IP). Then the senders transmit packets as given by a rateless erasure code encoding of the original file, and mark the packets with a fake source IP address. This works because erasure codes don't need any regular ACK-type feedback. Now add something like EigenTrust (or a robust variant of it) on top of the DHT to get rid of fake file uploads, and proof the erasure code against the case where some "senders" just pretend to have the file and send noise instead (there's a paper of how to do this, but I can't remember its title at the moment), and you're all set.
In the worst case, ISPs would implement egress filtering. That, itself, isn't a bad thing (as it prevents reflection denial-of-service attacks), and so in either case we win. And that was just a first stab; clever people could probably find some way of masquerading it as HTTPS, use secret sharing to say "but I wasn't really sharing the file, just a part of it", or whatever.
I remember stories about viruses that could infect the computer human user.
It's called an e-mail chain letter or virus hoax, and infects the minds of gullible users.
And here I thought it was Employee 2-4601 all along...
Your name wouldn't be Vizzini, by any chance?
I believe their reasoning is that most games are sold the first few days and that adding these schemes slow down the pirates, thus making more people buy the game when they see the alternative is having to wait until the crack is done.
But what EA and their ilk may gain through delaying pirates this way, they lose by the schemes being so convoluted and impractical that legitimate customers purposefully search for the pirated copy so they can play something that's Better Than Original.
That is liquid metal... it's just that the molecules are inches across.
In the voice of Kosh, "yes".
You can't see it because the tracker is slashdotted, but someone did submit a patch. The developers effectively said "No, it's going to be too much trouble checking all the additional cases, so forget it". He then went and made a plugin instead, and asked the developers if they could include it in the default install. Again they said no, but I don't remember for what reason. After all of this, another person (ConnorBehan) forked the code. Extreme reaction? Perhaps, but they didn't see any other option.
(Check the tracker when it goes back up, and you'll get the details.)