"Emerging encryption technologies" such as Gentry's doubly-homomorphic encryption (which is what the link points to) tend to have a major disadvantage: they tend to be horribly inefficient. We're talking 6 orders of magnitude minimum, probably more like 12 orders. Unless there's a major breakthrough, this is not going to help.
Cryptographic engineering solutions, like DRM, might help. But then again, they might not: they require lots of engineering effort from the cloud providers, which they have little incentive to perform; and even then, DRM technologies don't have the greatest security record.
Operating system security measures will probably be very useful to protect against attacks, not from the hosting provider, but from other clients. These measures are tricky and unlikely to provide "perfect" security, but can definitely make attacks much more difficult.
I predict that after conventional defenses are applied, the solution will be either be less paranoid, or don't move to the cloud.
Yes, but a footnote in the operator's manual warns against operating near any sort of combustible material, because MegaCorp knows how to cover its collective ass.
Lawsuits aren't usually simple, which is why I agree that judges should have discretion in cases like this.
If it was a candle, that's one thing. But any electrical device connected to mains power could short-circuit, overheat and set the whole place ablaze. This includes at least his lights, electronics and prolly a dozen heavy appliances.
Or do you Norwegians turn off the heat at night and throw the breakers?
This wouldn't help as much as you might think. Legal services are expensive. CommonMan probably can't afford a lawyer unless he wins, so even if he only has to pay "normal" attorney's fees, losing probably bankrupts him anyway. It basically negates the advantages of contingency.
IIRC they claim 2.5-3x times more performance using a Tesla than using the CPUs in their workstation. Ignoring load time.
Their CPU numbers almost certainly take SIMD into account.
I'm doing cryptography research, and some of my colleagues have been considering building a similar "desktop supercomputer". The speedup there looks more reasonable: a single high-end GPU should be worth maybe 5-10 quad-core CPUs; it costs double and uses double the power, but it's easier to put a dozen of them in a single PC. The numbers aren't as good as for big matrices of floats, but that's because we're doing integer operations and GPUs aren't optimized for those. (But then again, crypto problems tend to set the standard for embarrassingly parallel problems.)
Anyway, the new "box-fulla-GPUs" supercomputers sure beat the heck out of the previous generation of cheap scientific compute cluster: a hundred PS3s running linux.
Long-term exposure to nicotine isn't good for you either, kind of like long-term exposure to caffeine. It at least causes heart and stomach problems. But it's much more addictive than caffeine.
It costs on the order of $10k to sequence a single genome. But you wouldn't do it for every cancer patient. Instead, you'd do it for a couple hundred cancer patients, and study the results. You'd hope to find a few dozen common mutations which indicate which treatment to use. Checking a cancer for a few dozen known marker genes is considerably easier than sequencing an entire genome.
Suppose that a faulty MegaCorp device burns Middle Class Joe's house to the ground. Joe tries to sue MegaCorp, but all he can afford is an average lawyer working on contingency. MegaCorp sends the dream team. If Joe wins, then MegaCorp has to pay him and his average lawyer. Sounds good: Joe gets more money. But if he loses, MegaCorp bankrupts him because even though his own lawyer is working on contingency, he has to pay MegaCorp's dream team. This provides a strong disincentive to bring suit.
It's even worse if the defendant automatically pays when losing. In this case, if the MAFIAA sues you, you defend yourself and you lose, you'll have to pay not only the ridiculous statutory damages, but also attorney's fees.
Of course, there are ways to fix this. The most obvious way is for the judge to have discretion on whether the loser pays, but caps on the fees might work almost as well.
But EMI don't own the particular soundwaves which comprise the Beatles' songs. Instead they own the very idea of these songs. EMI has sole and total ownership over the platonic ideals of which any particular instance of a Beatles song is merely a shadow. This ideal encompases any sound resembling the songs, any text resembling their lyrics, any album cover resembling theirs, any musical notes close enough to a Beatles tune.
This isn't quite true for copyrights, at least in theory. EMI has a claim on basically any work which is derived from a significant portion of a Beatles song. They don't have a claim on work which is similar to a Beatles song, unless it is derived from that song.
Copyright law is about provenance, not content. If someone who has never heard a Beatles song (nor looked at the score of one, etc) composes and records an exact replica of "Yellow Submarine", EMI doesn't own it. But good luck convincing a judge or jury of this.
So if this guy is "psychoacoustically simulating" a Beatles song, he's illegally preparing a derivative work.
Actually, this is a birthday attack. The point of a birthday attack is that with n samples, you have n(n-1)/2 possible collisions. Usually people call this n^2/2 or "about n^2".
When probabilities are so small, they more or less add. So the odds are about n^2 / (2*space) that you find a collision with n objects. So long as this number doesn't get close to 1, the approximation is accurate enough. (You could try to evaluate the formula you gave, or something very much like it, but the factorials are so large you'd have to approximate anyway.)
If you choose n close to 2^128, the probability becomes close to 1 and you have to choose a better approximation to find it. This gives you a way to find a collision with meaningful probability if you can hash about 2^128 random numbers and store the hashes. Obviously, this is not going to happen (yadda yadda boil the oceans yadda), but it means that it takes "about 2^128 effort" to break SHA256.
On the other hand, if you choose n = 8M, this gives about 8M^2 / 2^257 or 2.76e-64 probability of finding a collision. This is about the same probability as two meteors colliding in midair in your living room.
If SHA256 behaves randomly, the odds are considerably lower than that. The odds are on the order of n^2 / 2^256, where n is the number of blocks. Here n is about 8*10^6, so the odds are between 10^-64 and 10^-63.
If you only assume that SHA256 is collision-resistant, the odds might be more like the 10^-32 you suggested, but this seems unlikely. If such a problem were discovered, it would cause SHA256 to fall out of favor. People want their hash functions to behave randomly. (You could use a universal hash function and guarantee odds of 10^-64. But this would be a security disaster if an attacker somehow recovered the key.)
Still, many people will not accept heuristic or probabilistic solutions to deterministic problems, because they don't trust the heuristic and/or don't want to increase their chances of failure.
Actually, 2^64 bytes is exactly 16 exbibytes. But of course, that's the address space. You have to have some of it reserved for physical addresses, and some for the graphics card, some for memory-mapped I/O, and a whole bunch more for Stupid VM Tricks.
VIA Nano is 64-bit. Dunno how its price/performance/power compares to an undervolted desktop CPU or cheap laptop CPU. It's definitely faster, more power hungry and more expensive than an Atom. But like the Atom, it's also definitely available in Mini-ITX.
I am required, by the rules of the GPL, to give my customer the source, and they are allowed to do whatever they want, including give it to others, but if they paid $1,000,000 for it, chances are they're not going to do that.
True, but they might sell it to another would-be customer for $500,000. Which you might not be happy with.
I'm somewhat surprised that there are no published timing attacks against TrueCrypt's AES implementation. Attacks against 128-bit AES are certainly easier, but there's a public attack that breaks Linux's dm-crypt in 65ms of testing and 3s of computation, and 256-bit AES shouldn't be immune.
Exactly! And why require a password to log in? After all, the connection is encrypted!
Seriously, it is not particularly meaningful to have encryption without authentication. People talk about it being hard to set up MITM (man-in-the-middle) attacks, but the truth of the matter is that if you can listen to someone's traffic, it's probably because you're their ISP, or you're the gov't, or they're using unencrypted wireless, or you set up a rogue WAP, or you hacked their router... and in these cases you can MITM them too. Designing the MITM software is an early assignment in many network security classes... anyone with a bit of programming knowledge can do it, and once someone does it and releases the tool, everyone else can do it too. The only difference here is that the attack is slightly more visible, because if the browser shows a warning on cert changes (which happen pretty frequently, by the way) then a very savvy user might catch it, report it to the media, and then the attacker would have egg (read: a lawsuit) on their face. Unless they're the Russian mafia, an anonymous Estonia hacker, or a company with enough $$$ to defend themselves.
And this is why browser designers don't want to allow two kinds of certs. It's well-known that most people don't understand computer security; that's even what this study is showing. People will believe that their connection is secure because it's encrypted with 128-bit AES, 4096-bit RSA and 8-million-bit pixie dust, but in the end it's only marginally more secure than it was before. And as I posted above, to a cryptographer, crypto that does not protect a user from reasonably expected cryptographic threats is an abomination.
Of course, it is still possible to social-engineer a CA, break a hash function, or whatever. But you have to do this and get in the middle, which raises the bar at least a little bit.
There's actually a very good reason for all this, and it doesn't have anything to do with monopolistic CAs in cahoots with browser vendors.
The reason is that cryptographers don't want cryptography to be the weak link if it can possibly be avoided. HTTPS with a self-signed cert is slightly more secure than plaintext, but it's a cryptographic protocol that admits a cryptographic attack, and if you're a cryptographer, this is an abomination.
Now, as plenty of other posters have pointed out, you can warn the user when the certificate changes. This defeats the attacker unless he gets in the middle the first time you connect from a given machine; it's called the "duckling security model" and is used by SSH. There are two problems with this security model. One is that admitting a cryptographic attack the first time you connect is still pretty bad. The other is that there are legitimate reasons to change certificates. You might have a SNAFU like with Debian, or you might add more domains or flags to the cert. Or the cert might just expire, which is good practice: it reduces the utility of compromising the cert. When this happens, you need to present a really big scary warning (scarier than the current firefox one), because it's indistinguishable from a real attack.
Of course, you could mitigate this risk by signing the new cert with the old one. You would have to not trust all the features of the new cert without showing a warning (requires careful engineering!), but it could be done.
But this requires changing how SSL works in a more fundamental way. And if we're going down that path, SSL ought to be extended with Password Authenticated Key Exchange (actually, with a new design by Xavier Boyen that's unpatented and better than PAKE) in most cases. For sites where you have to log in with a password, PAKE gives you the duckling security model on any machine: you can log in from any machine, and the server is authenticated by the fact that it knows a certain function of your password; its cert doesn't matter at all.
It's a time/memory/data trade-off. If you have 2^128 AES-256-encrypted copies of a known plaintext, you can already find one of the keys using 2^128 time. You just encrypt using 2^128 random keys and find collisions.
This attack does better by a factor of 2^9 = 512 if the keys are related in some way known to (or maybe chosen by) the attacker. They think they can get another factor of 2^9 out of it with a more careful analysis. Even so, this is only a theoretical weakness.
Well, if an application is written to use threads, then it is both parallel and concurrent, in that the threads could be run on different cores/processors/whatever if they are available.
Not really. Most threaded apps have at most one CPU-intensive thread. The threads are about concurrency, not parallelism... you just want to make sure that mostly-independent parts of the app don't block each other. Usually either everything is waiting for input or just the CPU-heavy thread is running. These apps benefit very little from multicore.
For example, Firefox is threaded (poorly), but it isn't particularly parallel: it rarely or never brings the CPU over 100%, so it can't take much advantage of a dual-core CPU. It could theoretically be made parallel by pipelining or otherwise parallelizing the renderer, or making it run in parallel with the Javascript engine, but these are hard enough and gains small enough that they won't happen anytime soon.
I hear you, and I bike to work rain or shine (but only 2 miles). Still, there are some serious disadvantages of a bike.
In the rain, it's much harder to see anything than in a car (particularly with glasses), and coat or no coat, it is considerably less comfortable than in a car.
Splash guards take care of the "brown stripe" problem well enough, but you still have to be careful not to get bike grease on your stuff. I've ruined a few pairs of pants by absentmindedly hopping on the bike without pinning up, or by parking the bike and brushing my leg against the chain. Even my hat has some "character"... got greased up while strapped to the rack or in one of the baskets... dunno how exactly. I would not want to ride with a suit.
Carrying capacity is pretty limited, even with rack+baskets+backpack. 30 pounds of groceries for 5 miles, fine, but a CostCo run is out of the question. Furniture, computers etc are also more difficult (I did haul a desk chair once, though). What's more, the lack of suspension makes carrying glass, eggs, etc a risky proposition.
And of course, it makes a long, tiring day full of errands even longer and more tiring.
On the other hand, biking is the only fast way to get around my campus. Parking is hideously expensive, there are bollards all over, and it's too big to walk everywhere. Plus, it helps keep you in shape.
Slashdot Mirror
"Emerging encryption technologies" such as Gentry's doubly-homomorphic encryption (which is what the link points to) tend to have a major disadvantage: they tend to be horribly inefficient. We're talking 6 orders of magnitude minimum, probably more like 12 orders. Unless there's a major breakthrough, this is not going to help.
Cryptographic engineering solutions, like DRM, might help. But then again, they might not: they require lots of engineering effort from the cloud providers, which they have little incentive to perform; and even then, DRM technologies don't have the greatest security record.
Operating system security measures will probably be very useful to protect against attacks, not from the hosting provider, but from other clients. These measures are tricky and unlikely to provide "perfect" security, but can definitely make attacks much more difficult.
I predict that after conventional defenses are applied, the solution will be either be less paranoid, or don't move to the cloud.
And yes, I am a cryptographer.
Is this known to be the cause of the fire?
Yes, but a footnote in the operator's manual warns against operating near any sort of combustible material, because MegaCorp knows how to cover its collective ass.
Lawsuits aren't usually simple, which is why I agree that judges should have discretion in cases like this.
If it was a candle, that's one thing. But any electrical device connected to mains power could short-circuit, overheat and set the whole place ablaze. This includes at least his lights, electronics and prolly a dozen heavy appliances.
Or do you Norwegians turn off the heat at night and throw the breakers?
Or have I been trolled?
This wouldn't help as much as you might think. Legal services are expensive. CommonMan probably can't afford a lawyer unless he wins, so even if he only has to pay "normal" attorney's fees, losing probably bankrupts him anyway. It basically negates the advantages of contingency.
Their CPU numbers almost certainly take SIMD into account.
I'm doing cryptography research, and some of my colleagues have been considering building a similar "desktop supercomputer". The speedup there looks more reasonable: a single high-end GPU should be worth maybe 5-10 quad-core CPUs; it costs double and uses double the power, but it's easier to put a dozen of them in a single PC. The numbers aren't as good as for big matrices of floats, but that's because we're doing integer operations and GPUs aren't optimized for those. (But then again, crypto problems tend to set the standard for embarrassingly parallel problems.)
Anyway, the new "box-fulla-GPUs" supercomputers sure beat the heck out of the previous generation of cheap scientific compute cluster: a hundred PS3s running linux.
(Is that the smell of burning Karma?)
No, that's petrified grits you're smelling.
Long-term exposure to nicotine isn't good for you either, kind of like long-term exposure to caffeine. It at least causes heart and stomach problems. But it's much more addictive than caffeine.
It costs on the order of $10k to sequence a single genome. But you wouldn't do it for every cancer patient. Instead, you'd do it for a couple hundred cancer patients, and study the results. You'd hope to find a few dozen common mutations which indicate which treatment to use. Checking a cancer for a few dozen known marker genes is considerably easier than sequencing an entire genome.
Suppose that a faulty MegaCorp device burns Middle Class Joe's house to the ground. Joe tries to sue MegaCorp, but all he can afford is an average lawyer working on contingency. MegaCorp sends the dream team. If Joe wins, then MegaCorp has to pay him and his average lawyer. Sounds good: Joe gets more money. But if he loses, MegaCorp bankrupts him because even though his own lawyer is working on contingency, he has to pay MegaCorp's dream team. This provides a strong disincentive to bring suit.
It's even worse if the defendant automatically pays when losing. In this case, if the MAFIAA sues you, you defend yourself and you lose, you'll have to pay not only the ridiculous statutory damages, but also attorney's fees.
Of course, there are ways to fix this. The most obvious way is for the judge to have discretion on whether the loser pays, but caps on the fees might work almost as well.
The Indians already have a word for 10 million cores.
But EMI don't own the particular soundwaves which comprise the Beatles' songs. Instead they own the very idea of these songs. EMI has sole and total ownership over the platonic ideals of which any particular instance of a Beatles song is merely a shadow. This ideal encompases any sound resembling the songs, any text resembling their lyrics, any album cover resembling theirs, any musical notes close enough to a Beatles tune.
This isn't quite true for copyrights, at least in theory. EMI has a claim on basically any work which is derived from a significant portion of a Beatles song. They don't have a claim on work which is similar to a Beatles song, unless it is derived from that song.
Copyright law is about provenance, not content. If someone who has never heard a Beatles song (nor looked at the score of one, etc) composes and records an exact replica of "Yellow Submarine", EMI doesn't own it. But good luck convincing a judge or jury of this.
So if this guy is "psychoacoustically simulating" a Beatles song, he's illegally preparing a derivative work.
The upside in this is that the lights still work when the controller is down. They don't go flashing red, stay red, turn off or something worse.
Actually, it might be closer to the chance of 3 meteors colliding in midair in your living room.
Actually, this is a birthday attack. The point of a birthday attack is that with n samples, you have n(n-1)/2 possible collisions. Usually people call this n^2/2 or "about n^2".
When probabilities are so small, they more or less add. So the odds are about n^2 / (2*space) that you find a collision with n objects. So long as this number doesn't get close to 1, the approximation is accurate enough. (You could try to evaluate the formula you gave, or something very much like it, but the factorials are so large you'd have to approximate anyway.)
If you choose n close to 2^128, the probability becomes close to 1 and you have to choose a better approximation to find it. This gives you a way to find a collision with meaningful probability if you can hash about 2^128 random numbers and store the hashes. Obviously, this is not going to happen (yadda yadda boil the oceans yadda), but it means that it takes "about 2^128 effort" to break SHA256.
On the other hand, if you choose n = 8M, this gives about 8M^2 / 2^257 or 2.76e-64 probability of finding a collision. This is about the same probability as two meteors colliding in midair in your living room.
If SHA256 behaves randomly, the odds are considerably lower than that. The odds are on the order of n^2 / 2^256, where n is the number of blocks. Here n is about 8*10^6, so the odds are between 10^-64 and 10^-63.
If you only assume that SHA256 is collision-resistant, the odds might be more like the 10^-32 you suggested, but this seems unlikely. If such a problem were discovered, it would cause SHA256 to fall out of favor. People want their hash functions to behave randomly. (You could use a universal hash function and guarantee odds of 10^-64. But this would be a security disaster if an attacker somehow recovered the key.)
Still, many people will not accept heuristic or probabilistic solutions to deterministic problems, because they don't trust the heuristic and/or don't want to increase their chances of failure.
There, the ultimate slashdot meme...
Just imagine a Beowulf cluster of those!
Actually, 2^64 bytes is exactly 16 exbibytes. But of course, that's the address space. You have to have some of it reserved for physical addresses, and some for the graphics card, some for memory-mapped I/O, and a whole bunch more for Stupid VM Tricks.
Still, not gonna happen anytime soon.
VIA Nano is 64-bit. Dunno how its price/performance/power compares to an undervolted desktop CPU or cheap laptop CPU. It's definitely faster, more power hungry and more expensive than an Atom. But like the Atom, it's also definitely available in Mini-ITX.
I am required, by the rules of the GPL, to give my customer the source, and they are allowed to do whatever they want, including give it to others, but if they paid $1,000,000 for it, chances are they're not going to do that.
True, but they might sell it to another would-be customer for $500,000. Which you might not be happy with.
I'm somewhat surprised that there are no published timing attacks against TrueCrypt's AES implementation. Attacks against 128-bit AES are certainly easier, but there's a public attack that breaks Linux's dm-crypt in 65ms of testing and 3s of computation, and 256-bit AES shouldn't be immune.
Those attacks shouldn't require admin privileges.
Exactly! And why require a password to log in? After all, the connection is encrypted!
Seriously, it is not particularly meaningful to have encryption without authentication. People talk about it being hard to set up MITM (man-in-the-middle) attacks, but the truth of the matter is that if you can listen to someone's traffic, it's probably because you're their ISP, or you're the gov't, or they're using unencrypted wireless, or you set up a rogue WAP, or you hacked their router... and in these cases you can MITM them too. Designing the MITM software is an early assignment in many network security classes... anyone with a bit of programming knowledge can do it, and once someone does it and releases the tool, everyone else can do it too. The only difference here is that the attack is slightly more visible, because if the browser shows a warning on cert changes (which happen pretty frequently, by the way) then a very savvy user might catch it, report it to the media, and then the attacker would have egg (read: a lawsuit) on their face. Unless they're the Russian mafia, an anonymous Estonia hacker, or a company with enough $$$ to defend themselves.
And this is why browser designers don't want to allow two kinds of certs. It's well-known that most people don't understand computer security; that's even what this study is showing. People will believe that their connection is secure because it's encrypted with 128-bit AES, 4096-bit RSA and 8-million-bit pixie dust, but in the end it's only marginally more secure than it was before. And as I posted above, to a cryptographer, crypto that does not protect a user from reasonably expected cryptographic threats is an abomination.
Of course, it is still possible to social-engineer a CA, break a hash function, or whatever. But you have to do this and get in the middle, which raises the bar at least a little bit.
There's actually a very good reason for all this, and it doesn't have anything to do with monopolistic CAs in cahoots with browser vendors.
The reason is that cryptographers don't want cryptography to be the weak link if it can possibly be avoided. HTTPS with a self-signed cert is slightly more secure than plaintext, but it's a cryptographic protocol that admits a cryptographic attack, and if you're a cryptographer, this is an abomination.
Now, as plenty of other posters have pointed out, you can warn the user when the certificate changes. This defeats the attacker unless he gets in the middle the first time you connect from a given machine; it's called the "duckling security model" and is used by SSH. There are two problems with this security model. One is that admitting a cryptographic attack the first time you connect is still pretty bad. The other is that there are legitimate reasons to change certificates. You might have a SNAFU like with Debian, or you might add more domains or flags to the cert. Or the cert might just expire, which is good practice: it reduces the utility of compromising the cert. When this happens, you need to present a really big scary warning (scarier than the current firefox one), because it's indistinguishable from a real attack.
Of course, you could mitigate this risk by signing the new cert with the old one. You would have to not trust all the features of the new cert without showing a warning (requires careful engineering!), but it could be done.
But this requires changing how SSL works in a more fundamental way. And if we're going down that path, SSL ought to be extended with Password Authenticated Key Exchange (actually, with a new design by Xavier Boyen that's unpatented and better than PAKE) in most cases. For sites where you have to log in with a password, PAKE gives you the duckling security model on any machine: you can log in from any machine, and the server is authenticated by the fact that it knows a certain function of your password; its cert doesn't matter at all.
It's a time/memory/data trade-off. If you have 2^128 AES-256-encrypted copies of a known plaintext, you can already find one of the keys using 2^128 time. You just encrypt using 2^128 random keys and find collisions.
This attack does better by a factor of 2^9 = 512 if the keys are related in some way known to (or maybe chosen by) the attacker. They think they can get another factor of 2^9 out of it with a more careful analysis. Even so, this is only a theoretical weakness.
Well, if an application is written to use threads, then it is both parallel and concurrent, in that the threads could be run on different cores/processors/whatever if they are available.
Not really. Most threaded apps have at most one CPU-intensive thread. The threads are about concurrency, not parallelism... you just want to make sure that mostly-independent parts of the app don't block each other. Usually either everything is waiting for input or just the CPU-heavy thread is running. These apps benefit very little from multicore.
For example, Firefox is threaded (poorly), but it isn't particularly parallel: it rarely or never brings the CPU over 100%, so it can't take much advantage of a dual-core CPU. It could theoretically be made parallel by pipelining or otherwise parallelizing the renderer, or making it run in parallel with the Javascript engine, but these are hard enough and gains small enough that they won't happen anytime soon.
I hear you, and I bike to work rain or shine (but only 2 miles). Still, there are some serious disadvantages of a bike.
In the rain, it's much harder to see anything than in a car (particularly with glasses), and coat or no coat, it is considerably less comfortable than in a car.
Splash guards take care of the "brown stripe" problem well enough, but you still have to be careful not to get bike grease on your stuff. I've ruined a few pairs of pants by absentmindedly hopping on the bike without pinning up, or by parking the bike and brushing my leg against the chain. Even my hat has some "character"... got greased up while strapped to the rack or in one of the baskets... dunno how exactly. I would not want to ride with a suit.
Carrying capacity is pretty limited, even with rack+baskets+backpack. 30 pounds of groceries for 5 miles, fine, but a CostCo run is out of the question. Furniture, computers etc are also more difficult (I did haul a desk chair once, though). What's more, the lack of suspension makes carrying glass, eggs, etc a risky proposition.
And of course, it makes a long, tiring day full of errands even longer and more tiring.
On the other hand, biking is the only fast way to get around my campus. Parking is hideously expensive, there are bollards all over, and it's too big to walk everywhere. Plus, it helps keep you in shape.