Instead we have people like you who use up public resources to produce something that the private sector could produce more readily.
Why do you think the private sector could produce this "something" more readily? Although many CS research projects are funded by the government (mainly the NSF these days), many are funded by industry, and it doesn't make a major impact on the efficiency of the students in carrying out research.
As for the free software movement, we don't make many new algorithms, we just use existing ones.
I must be very confused by the way you're using the world "algorithm" since this just doesn't make any sense to me. There are loads of algorithms created by free software hackers. Many are derived from academic work. (bzip, rsync, FFTW, bittorrent are good examples.) Most of the Internet protocols come from this same community. Corporations produce algorithms, too, but I just can't take your word for it that that there is some huge disconnect, since this contradicts my experience.
As a graduate student working in computer science, I don't agree that the progress of CS is slow at all, so I can't follow the argument that there is need for new incentives.
Isn't the free software movement another source of progress? This is composed of loads of people who can "afford" to invent software, with little more incentive than "cool" points among their peers.
Patents are for ideas. One doesn't patent each pill in a new drug line or each jet turbine his company produces, he patents the formula of (and process for manufacturing) the drug and design of the turbine.
I'm not the biggest fan of patents, but the argument you're making here doesn't make sense.
Patents exist only in order to encourage innovation. This much is essentially in the Constitution, because the right for congress to create patent and copyright laws is preceded by "To promote the Progress of Science and the useful Arts..."
The way that patents encourage innovation is to provide an incentive to expend resources to create an invention. The incentive is the exclusive right to use that invention. Many inventions take millions of dollars to create, so the patent plays an important role for those inventions, at least with the way our society currently operates.
Here's the rub: most software inventions do not take millions of dollars to create, since the resources involved are almost always simply a guy and a computer (or pencil and paper). We've seen this many times, as fairly obvious ideas are re-invented, or old, overly generic patents are applied to unrelated inventions years later. Here, patents stifle innovation instead of promoting it. There already exists an incentive to invent, and since it is so easy to do so, patents just provide an unnecessary friction.
There are also many specific problems with software patents. The term is too long considering the pace at which the field moves. The patent office is woefully underequipped to evaluate software patent applications. Patents are often incompatible with free software, which has shown to provide a huge amount of value (for the Progress of Science and the useful Arts!), probably more than software patents ever have.
Awful! The least the author could do is spell and punctuate the article correctly.
I get the point that the house is ridiculous, but I don't understand the analogy with the specific failings of software design. My guess is because there is no analogy beyond "they are both bad." How did this get slashdotted?
I strongly disagree that there is a "right" or "wrong" endianness. x86 has its problems, but this is certainly not something to dwell on. It's sort of like saying that you can't stand England because they drive on the "wrong side of the road."
I don't understand why you're concerned. Do you think that the reason that developers wrote software for OS X in the past was that they really liked PowerPC? I mean, the architecture is slightly nicer than the x86 (what isn't?) but most programs are written in a form that will compile trivially for any architecture. From a developer's perspective, what's the big deal?
One positive aspect of this is that any code tuned for the x86 (ie, DOOM 5 or whatever) will be able to run on Mac immediately, so I expect that the Mac will get applications like that much sooner.
Wind Waker was fucken sweet, and a large part of that was its beautiful graphics. My heart sank when I learned the new Zelda wouldn't be in a similar style.
Worldwide revenue loss due to software piracy was estimated at $33 billion
Remember that since piracy costs almost nothing to do, this revenue loss is also a corresponding revenue gain for those who pirate. So another way to say this is, "Due to piracy, the world gained $33 billion dollars worth of software without spending a dime." It doesn't sound so bad when you put it that way, huh?
Allegedly the OpenSSL code has over 1000 data-dependent if-statements
I don't doubt it, and it would likely take a rewrite of the RSA code. But RSA is a very simple algorithm, so I believe it can be done without much trouble if one doesn't obsess over efficiency.
Practically speaking, just fixing modular exponentiation (which is the core of encoding and decoding) to call exactly the same bn_ functions whether the key bit is 0 or 1 would seem to fix this particular problem.
This appears to be an application bug, not a kernel one. The kernel never claims to completely isolate processes from one another; though there are memory protections, there are loads of ways that processes can observer each other's actions. This is just a particularly high-resolution one.
The real "bug" here, IMO, is that openSSL believes that no other process can observe anything about its secret computations. Timing attacks against RSA have been known for some time, particularly with regard to modular exponentiation.
It wouldn't be too hard to make RSA encryption take the same amount of time no matter what code path is used, and to make its memory access patterns uncorrelated with the keys (perhaps by using randomization during allocation). They should do this--the fact that their application leaks information has nothing to do with the processor it's running on; it's just that HT makes it particularly easy to measure that information. This would have a performance penalty, and I think the OpenBSD folks are too obsessed with performance, and that's why they've not done this. The performance obsession is a serious problem in the Unix world, and software systems in general.
If implementing openSSL effectively means adding special kernel support for things like constant-length timeslices or cache invalidation between context switches, that's fine. But this is not a bug in the kenel unless the kernel purports to enforce total separation between processes, which it certainly does not.
It took them a year and a half of computer time on, I believe, a cluster. I am arguing that that computational resource was wasted (plust the cost of powering and maintaining the cluster, etc.).
Like I said, actual cracked keys are far easier to justify to a programmer than theoretical calculations. Actual cracked keys can be trusted 100%. Calculations of performance from unknown researches can be trusted much less than that.
I strongly disagree. A theoretical analysis is better because you can prove that it works for all cases (not just the one you experimentally verify), and because you get a more accurate picture for a probabilistic algorithm.
I guess I didn't make myself clear. (clarification post) I whole-heartedly endorse the implementation of algorithms. But once we know it's going to take 1.5 years to run, we shouldn't bother actually running them for 1.5 years!
these challenges show just how good public-key cryptography is, and what is technically feasible to break.
We can know that by paper-and-pencil calculations, once we know how fast our implementation is. And we can know it 1.5 years sooner!
I said it's worthwhile to make good implementations. I think we should do this. Then, based on our understanding of the code's behavior (and probably some short-lived experiments), we can extrapolate to find the expected time to completion. This is also better for randomized algorithms that actually running it, since by running it we only get one point randomly sampled from the probability distribution. They clearly knew that the experiment would take approximately 1.5 years to run, otherwise they wouldn't run it.
What we should not do is, once we figure out how long something is going to take, to actually run it if the answer is totally pointless. This last step is a waste of time.
I think these RSA challenges are a waste of computer power. It's trivial to compute how much computing resources it will take to factor numbers using an existing algorithm on paper, and you get a more accurate estimate than you get from sampling experimentally. I'm all for the development of new, faster algorithms and implementations, but the challenge should be for the development and demonstration of these algorithms, not the brute-force months-on-end search that ensues.
The stats reset made perfect sense. Lots of people had high ranks because of abuse (the bugs were numerous and explotation was rampant), and now that the playlists have changed, the engine modified, and levels have been added, the game is quite different. It's true that matchmaking will be a bit screwed up for a little while, but all that means is that people will gain their true ranks much more quickly.
I, for one, welcome our new no games played overlords.
But no one has ever found evidence that calculating finer and finer values of pi will ever reveal an end to the string or that there is any regular pattern to be found within it.
I'd say the ancient proof that pi is irrational counts as pretty strong evidence that we will never find an end to the string. Duh.
Yeah, this is one of the most common problems with devices that have plugs, and you can usually fix it with soldering. Generally, your solder joints won't last as long as the original bad joints did in the first place, so this "repair" won't be particularly permanent unless you do something like mount the connector to the chassis and connect it to the PCB with flexible wires instead. Soldering is not too hard, but for something that costs $600, you might not want this to be your first attempt.
I did a laughably sloppy job of this with my MP3 player a year or so ago and posted the steps and pictures. You probably don't want to be this sloppy.
In all likelihood this is bullshit. Let me try to read between the lines and give the most generous guess at what they're doing that I can come up with.
They mention DRM, so it would seem that they intend to have control over the original encoded files. Recall that P2P apps often break the file into smaller chunks, which are identified by their hashes and then downloaded individually. Then, one way to screw with P2P downloading would be to arrange so that chunks of the original files all have the same hash (or the same hash as various other data that is injected into the network by attackers). Generating collisions is known to be possible (you might be able to even just use the published collisions by Wang et al. if the P2P app uses the standard MD5 IV, and then include an equal and randomly-generated suffix). Downloading using current methods would then likely corrupt the file, which could be checked by the DRM software.
This is pretty easy to fix in current P2P software by moving to hashes for which it is unknown how to generate collisions. (Or checking the hash of the entire file at the end, which no doubt some programs already do.) Also, since sharers don't generally start with DRM'd source material, a key assumption is violated.
Even publishing the algorithms isn't enough since the results are generated by the actual program, not the planned program.
If it's not good enough, then the journal should have rejected the paper. The scientific community sets these standards already.
This is analogous to mathematicians publishing their proofs.
I agree, and mathematicians often do NOT publish their proofs, especially when they are considered rote. (Rather, they explain them at a high level or, worse, simply state the theorem and that they have proved it!)
In both cases I believe that standards in the scientific community should be higher. However, I believe that the standards should be set by the scientific community, not by forcing publicly-funded scientists to publish all of their code indiscriminately.
Slashdot Mirror
Instead we have people like you who use up public resources to produce something that the private sector could produce more readily.
Why do you think the private sector could produce this "something" more readily? Although many CS research projects are funded by the government (mainly the NSF these days), many are funded by industry, and it doesn't make a major impact on the efficiency of the students in carrying out research.
As for the free software movement, we don't make many new algorithms, we just use existing ones.
I must be very confused by the way you're using the world "algorithm" since this just doesn't make any sense to me. There are loads of algorithms created by free software hackers. Many are derived from academic work. (bzip, rsync, FFTW, bittorrent are good examples.) Most of the Internet protocols come from this same community. Corporations produce algorithms, too, but I just can't take your word for it that that there is some huge disconnect, since this contradicts my experience.
As a graduate student working in computer science, I don't agree that the progress of CS is slow at all, so I can't follow the argument that there is need for new incentives.
Isn't the free software movement another source of progress? This is composed of loads of people who can "afford" to invent software, with little more incentive than "cool" points among their peers.
Patents are for ideas. One doesn't patent each pill in a new drug line or each jet turbine his company produces, he patents the formula of (and process for manufacturing) the drug and design of the turbine.
I'm not the biggest fan of patents, but the argument you're making here doesn't make sense.
Here's how I would put it.
Patents exist only in order to encourage innovation. This much is essentially in the Constitution, because the right for congress to create patent and copyright laws is preceded by "To promote the Progress of Science and the useful Arts..."
The way that patents encourage innovation is to provide an incentive to expend resources to create an invention. The incentive is the exclusive right to use that invention. Many inventions take millions of dollars to create, so the patent plays an important role for those inventions, at least with the way our society currently operates.
Here's the rub: most software inventions do not take millions of dollars to create, since the resources involved are almost always simply a guy and a computer (or pencil and paper). We've seen this many times, as fairly obvious ideas are re-invented, or old, overly generic patents are applied to unrelated inventions years later. Here, patents stifle innovation instead of promoting it. There already exists an incentive to invent, and since it is so easy to do so, patents just provide an unnecessary friction.
There are also many specific problems with software patents. The term is too long considering the pace at which the field moves. The patent office is woefully underequipped to evaluate software patent applications. Patents are often incompatible with free software, which has shown to provide a huge amount of value (for the Progress of Science and the useful Arts!), probably more than software patents ever have.
The lesson to be learned, don't listen to experts because they don't know what they're talking about ... and so I didn't read the article.
Awful! The least the author could do is spell and punctuate the article correctly.
I get the point that the house is ridiculous, but I don't understand the analogy with the specific failings of software design. My guess is because there is no analogy beyond "they are both bad." How did this get slashdotted?
I strongly disagree that there is a "right" or "wrong" endianness. x86 has its problems, but this is certainly not something to dwell on. It's sort of like saying that you can't stand England because they drive on the "wrong side of the road."
I don't understand why you're concerned. Do you think that the reason that developers wrote software for OS X in the past was that they really liked PowerPC? I mean, the architecture is slightly nicer than the x86 (what isn't?) but most programs are written in a form that will compile trivially for any architecture. From a developer's perspective, what's the big deal?
One positive aspect of this is that any code tuned for the x86 (ie, DOOM 5 or whatever) will be able to run on Mac immediately, so I expect that the Mac will get applications like that much sooner.
Man, we have had this in DOOM for like 10 years.
But they're so easy to render...
Wind Waker was fucken sweet, and a large part of that was its beautiful graphics. My heart sank when I learned the new Zelda wouldn't be in a similar style.
Worldwide revenue loss due to software piracy was estimated at $33 billion
Remember that since piracy costs almost nothing to do, this revenue loss is also a corresponding revenue gain for those who pirate. So another way to say this is, "Due to piracy, the world gained $33 billion dollars worth of software without spending a dime." It doesn't sound so bad when you put it that way, huh?
Allegedly the OpenSSL code has over 1000 data-dependent if-statements
I don't doubt it, and it would likely take a rewrite of the RSA code. But RSA is a very simple algorithm, so I believe it can be done without much trouble if one doesn't obsess over efficiency.
Practically speaking, just fixing modular exponentiation (which is the core of encoding and decoding) to call exactly the same bn_ functions whether the key bit is 0 or 1 would seem to fix this particular problem.
Why should this be fixed in the Kernel?
This appears to be an application bug, not a kernel one. The kernel never claims to completely isolate processes from one another; though there are memory protections, there are loads of ways that processes can observer each other's actions. This is just a particularly high-resolution one.
The real "bug" here, IMO, is that openSSL believes that no other process can observe anything about its secret computations. Timing attacks against RSA have been known for some time, particularly with regard to modular exponentiation.
It wouldn't be too hard to make RSA encryption take the same amount of time no matter what code path is used, and to make its memory access patterns uncorrelated with the keys (perhaps by using randomization during allocation). They should do this--the fact that their application leaks information has nothing to do with the processor it's running on; it's just that HT makes it particularly easy to measure that information. This would have a performance penalty, and I think the OpenBSD folks are too obsessed with performance, and that's why they've not done this. The performance obsession is a serious problem in the Unix world, and software systems in general.
If implementing openSSL effectively means adding special kernel support for things like constant-length timeslices or cache invalidation between context switches, that's fine. But this is not a bug in the kenel unless the kernel purports to enforce total separation between processes, which it certainly does not.
It took them a year and a half of computer time on, I believe, a cluster. I am arguing that that computational resource was wasted (plust the cost of powering and maintaining the cluster, etc.).
Like I said, actual cracked keys are far easier to justify to a programmer than theoretical calculations. Actual cracked keys can be trusted 100%. Calculations of performance from unknown researches can be trusted much less than that.
I strongly disagree. A theoretical analysis is better because you can prove that it works for all cases (not just the one you experimentally verify), and because you get a more accurate picture for a probabilistic algorithm.
I guess I didn't make myself clear. (clarification post) I whole-heartedly endorse the implementation of algorithms. But once we know it's going to take 1.5 years to run, we shouldn't bother actually running them for 1.5 years!
these challenges show just how good public-key cryptography is, and what is technically feasible to break.
We can know that by paper-and-pencil calculations, once we know how fast our implementation is. And we can know it 1.5 years sooner!
I said it's worthwhile to make good implementations. I think we should do this. Then, based on our understanding of the code's behavior (and probably some short-lived experiments), we can extrapolate to find the expected time to completion. This is also better for randomized algorithms that actually running it, since by running it we only get one point randomly sampled from the probability distribution. They clearly knew that the experiment would take approximately 1.5 years to run, otherwise they wouldn't run it.
What we should not do is, once we figure out how long something is going to take, to actually run it if the answer is totally pointless. This last step is a waste of time.
I think these RSA challenges are a waste of computer power. It's trivial to compute how much computing resources it will take to factor numbers using an existing algorithm on paper, and you get a more accurate estimate than you get from sampling experimentally. I'm all for the development of new, faster algorithms and implementations, but the challenge should be for the development and demonstration of these algorithms, not the brute-force months-on-end search that ensues.
The stats reset made perfect sense. Lots of people had high ranks because of abuse (the bugs were numerous and explotation was rampant), and now that the playlists have changed, the engine modified, and levels have been added, the game is quite different. It's true that matchmaking will be a bit screwed up for a little while, but all that means is that people will gain their true ranks much more quickly.
I, for one, welcome our new no games played overlords.
From the article:
But no one has ever found evidence that calculating finer and finer values of pi will ever reveal an end to the string or that there is any regular pattern to be found within it.
I'd say the ancient proof that pi is irrational counts as pretty strong evidence that we will never find an end to the string. Duh.
Yeah, this is one of the most common problems with devices that have plugs, and you can usually fix it with soldering. Generally, your solder joints won't last as long as the original bad joints did in the first place, so this "repair" won't be particularly permanent unless you do something like mount the connector to the chassis and connect it to the PCB with flexible wires instead. Soldering is not too hard, but for something that costs $600, you might not want this to be your first attempt.
I did a laughably sloppy job of this with my MP3 player a year or so ago and posted the steps and pictures . You probably don't want to be this sloppy.
Canon makes better gear anyway.
In all likelihood this is bullshit. Let me try to read between the lines and give the most generous guess at what they're doing that I can come up with.
They mention DRM, so it would seem that they intend to have control over the original encoded files. Recall that P2P apps often break the file into smaller chunks, which are identified by their hashes and then downloaded individually. Then, one way to screw with P2P downloading would be to arrange so that chunks of the original files all have the same hash (or the same hash as various other data that is injected into the network by attackers). Generating collisions is known to be possible (you might be able to even just use the published collisions by Wang et al. if the P2P app uses the standard MD5 IV, and then include an equal and randomly-generated suffix). Downloading using current methods would then likely corrupt the file, which could be checked by the DRM software.
This is pretty easy to fix in current P2P software by moving to hashes for which it is unknown how to generate collisions. (Or checking the hash of the entire file at the end, which no doubt some programs already do.) Also, since sharers don't generally start with DRM'd source material, a key assumption is violated.
Wow, I definitely don't want my windows to do this!
Even publishing the algorithms isn't enough since the results are generated by the actual program, not the planned program.
If it's not good enough, then the journal should have rejected the paper. The scientific community sets these standards already.
This is analogous to mathematicians publishing their proofs.
I agree, and mathematicians often do NOT publish their proofs, especially when they are considered rote. (Rather, they explain them at a high level or, worse, simply state the theorem and that they have proved it!)
In both cases I believe that standards in the scientific community should be higher. However, I believe that the standards should be set by the scientific community, not by forcing publicly-funded scientists to publish all of their code indiscriminately.