This is not a case of correlation vs. causality. In fact, we can pretty clearly say that if Farscape petitions are correlated to Farscape trailers, then Farscape petitions cause Farscape trailers. (Their temporal succession makes this a pretty easy argument, don't you think?) What we don't have data about is the correlation, since there has been just one experiment that we know of.
Yes. If you could, for instance, pad the end of a document with arbitrary data without making it invalid, then it is easy to see this being useful for an exploit.
Really, it all depends on what the technique is. But many formats have room for such padding, and all it takes is one forged Verisign signature to cause a lot of problems...
The paper that claims to have broken these says that the computation took 1 hour (with something like 15 seconds for subsequent collisions). Being able to generate collisions that quickly is a huge deal, and it has many applications -- it is often possible to "pad" a message with arbitrary data, so the data don't even have to have any particular format. It is scary to see all of these algorithms fall in the same week...
Well, just because something's freely downloadable doesn't mean that you have permission to copy it. It's kind of stupid, but that copyright stuff is a bummer, huh?
I agree with you, and there is a definite social and tool-availability pressures that make modern languages harder to use. But these problems are easily solved with a community effort, which is something that open source folks are good at!
I also agree that I think windows will see a real security benefit from the.NET CLR (maybe only because it will allow programmers to more easily integrate newer and more secure languages with the OS API), and I think it's sad that linux will have to play catch-up.
By the way, safe languages by no means need a VM. SML and O'Caml are both natively compiled, fast, and safe.
(This troll would be more effective if not posted anonymously.)
Indeed this flamewar has been repeated many times. Safe languages do indeed provide protection from these kinds of attacks and typically at a fairly small speed penalty (depending on the language; the number-two language on that list is safe and places above C++!).
See the earlier slashdot discussion for loads of argument. (here for my perspective--note, I am a tower-in-the-sky PhD student in programming languages, but I do write lots of code in many languages, including C and C++.) I am still boggled that programmers who claim to be interested in security (and who moreover claim to be uninfluenced by marketing and "cool", but rather by technical concerns) still choose C or C++ for their projects.
On the other hand, it's quite difficult for a bug to creep into a compiler's bounds checking code (which is typically very simple). I know of no such historic examples, though perhaps this is because relatively few apps actually use safe compiled languages. (It would presumably have to be matched by a bug in the application code...) Interpreters and JIT compilers are much more subject to this kind of problem, particularly if they are written in C themselves.;) There have been a few JVM exploits historically, though it is still much easier to make a secure JVM than to make tens of thousands of secure applications.
Finally, remember that even C has the burden of bugs in its compiler, runtime, and libraries, so this argument is useless at differentiating between C and safe compiled languages (unless you can argue that the latter have more complicated support code).
Yes, it could of course be prevented, like most other security holes. Java has a bad reputation for being slow, but there are plenty of natively-compiled languages that are quite fast and would at worst result in a denial-of-service (exception) if they had this bug, never execution of arbitrary code.
It is still a wonder to me that people who claim to be concerned about security choose C for their projects.
In order to use the GPL at all, you must copyright your software. So just copyrighting it will of course not be incompatible with the GPL!
Just time-stamping it is supposed to work, although it seems that they'll grant patents for anything, regardless of prior art, these days. It might make sense to try to publish any obvious minor variations on the idea, too.
I feel the same way. However, I think that I finally do see the light at the end of the tunnel. An artist working in 320x200 VGA space can certainly make careful use of pixels to provide a much better visual result than one gets from the Quake I engine. But as resolutions increase, the difference becomes much smaller: an artist working at high resolution is essentially working with vectors rather than pixels (think of a painter or cartoonist), and so in some sense has already lost his "pixel perfect" advantage.
It also seems that we are getting so much 3D power recently that it's no longer enough to simply have dazzling numbers of alpha-transparent triangles. 3D games are needing to resort to more interesting visual styles (cf Zelda: Wind Walker), and I think that may ultimately bring them to the same artistic levels that we see in modern "2D" games like the Capcom fighters or GBA side-scrollers.
I don't really think that this deserves the status of a "myths" page, since it simply responds to catch phrases with personal opinion. Usually a myths page responds with facts.
Anyway, the author seems to be deeply confused about a number of things. The most obvious is the distinction between the creation of software (which is a real service and which cannot in any sense be "free") and the duplication of software (which, as technology increases, has increasingly more negligible costs). None but the most deranged would argue that programmers should not be paid for the services that they render, should they choose to. Of course they must be, because there is nothing special about that service. On the other hand, the ability to duplicate and share software (and other digitized works) makes them a significantly different kind of product than food and clothing. Like the author's, any argument that fails to realize this distinction is likely specious.
One can argue that it is difficult to directly compensate programmers for their service, and that selling software provides a good indirect way to compensate them. I believe this model is ultimately doomed to fail because of free(dom) software alternatives, as the author also apparently does. But because we will typically have to pay for the service of creating software, this does not threaten the livelihood of programmers (except inasmuch as it reduces inefficiency and so makes some services not needed).
You could theoretically substitute hash-cash for real cash, but you still need an escrow system to do sender-risks.
Yes, this is what I said at the end. But when you look at it like this you suddenly realize that it is the power of the escrow agency that makes the ABM scheme work. The beauty of "sender pays" systems like hash cash is that no such thing is required.
This is an interesting theoretical design. I don't see why to put it into practice, though. "Hash Cash" accomplishes the same thing without using real money, and real money is dangerous because it's a lot more desirable than CPU time (what about iloveyou.vbs sending out high-bond e-mails to a special collection account? This is not a feature we can trust the average user to have enabled.) It also requires much more sophisticated machinery in place, like certificate authorities. (Of course, if we wanted to, we could also use certificate authorities to do post-hoc hash cash bonds. But if the algorithms can avoid certificate authorities, that is much better!)
Slashdot Mirror
This is not a case of correlation vs. causality. In fact, we can pretty clearly say that if Farscape petitions are correlated to Farscape trailers, then Farscape petitions cause Farscape trailers. (Their temporal succession makes this a pretty easy argument, don't you think?) What we don't have data about is the correlation, since there has been just one experiment that we know of.
Well, for one thing you can use error-correcting codes to translate that data density into robustness.
LILO: linux single
Let's just call this "3D imaging." Virtual reality has not been cool since 1996.
Here are collisions for the real, off-the-shell MD5 algorithm.
C:\tmp> sha1sum x1 x2
a34473cf767c6108a5751a20971f1fdfba97690a x1
4283dd2d70af1ad3c2d5fdc917330bf502035658 x2
C:\tmp> md5sum x1 x2
79054025255fb1a26e4bc422aef54eb4 x1
79054025255fb1a26e4bc422aef54eb4 x2
C:\tmp> hexdump x1
0000000 31d1 02dd e6c5 c4ee 3d69 069a af98 5cf9
0000010 ca2f 87b5 4612 ab7e 0440 3e58 fbb8 897f
0000020 ad55 0634 f409 02b3 e483 8388 7125 5a41
0000030 5108 e825 cdf7 9fc9 1dd9 f2bd 3780 5b3c
0000040 82d8 313e 3456 5b8f 6dae d4ac c936 c619
0000050 53dd b4e2 da87 fd03 3902 0663 48d2 a0cd
0000060 9fe9 4233 570f e87e 54ce 70b6 a880 1e0d
0000070 98c6 bc21 a8b6 9383 f996 2b65 f76f 702a
C:\tmp> hexdump x2
0000000 31d1 02dd e6c5 c4ee 3d69 069a af98 5cf9
0000010 ca2f 07b5 4612 ab7e 0440 3e58 fbb8 897f
0000020 ad55 0634 f409 02b3 e483 8388 f125 5a41
0000030 5108 e825 cdf7 9fc9 1dd9 72bd 3780 5b3c
0000040 82d8 313e 3456 5b8f 6dae d4ac c936 c619
0000050 53dd 34e2 da87 fd03 3902 0663 48d2 a0cd
0000060 9fe9 4233 570f e87e 54ce 70b6 2880 1e0d
0000070 98c6 bc21 a8b6 9383 f996 ab65 f76f 702a
Yes. If you could, for instance, pad the end of a document with arbitrary data without making it invalid, then it is easy to see this being useful for an exploit.
Really, it all depends on what the technique is. But many formats have room for such padding, and all it takes is one forged Verisign signature to cause a lot of problems...
The paper that claims to have broken these says that the computation took 1 hour (with something like 15 seconds for subsequent collisions). Being able to generate collisions that quickly is a huge deal, and it has many applications -- it is often possible to "pad" a message with arbitrary data, so the data don't even have to have any particular format. It is scary to see all of these algorithms fall in the same week...
... support for reading filesystems
Thank goodness. I've been having a hell of a time with these write-only filesystems.
Well, just because something's freely downloadable doesn't mean that you have permission to copy it. It's kind of stupid, but that copyright stuff is a bummer, huh?
I doubt Microsoft's bandwidth will suffer from this download.
... several important patents from the 1790's - including one from 1826 ...
Uh, 1826 is not in the 1790s.
ha-ha
There are targets that current VMs just can't meet.
True, but there exist several fine safe languages that don't use VMs.
I agree with you, and there is a definite social and tool-availability pressures that make modern languages harder to use. But these problems are easily solved with a community effort, which is something that open source folks are good at!
.NET CLR (maybe only because it will allow programmers to more easily integrate newer and more secure languages with the OS API), and I think it's sad that linux will have to play catch-up.
I also agree that I think windows will see a real security benefit from the
By the way, safe languages by no means need a VM. SML and O'Caml are both natively compiled, fast, and safe.
(This troll would be more effective if not posted anonymously.)
Indeed this flamewar has been repeated many times. Safe languages do indeed provide protection from these kinds of attacks and typically at a fairly small speed penalty (depending on the language; the number-two language on that list is safe and places above C++!).
See the earlier slashdot discussion for loads of argument. ( here for my perspective--note, I am a tower-in-the-sky PhD student in programming languages, but I do write lots of code in many languages, including C and C++.) I am still boggled that programmers who claim to be interested in security (and who moreover claim to be uninfluenced by marketing and "cool", but rather by technical concerns) still choose C or C++ for their projects.
On the other hand, it's quite difficult for a bug to creep into a compiler's bounds checking code (which is typically very simple). I know of no such historic examples, though perhaps this is because relatively few apps actually use safe compiled languages. (It would presumably have to be matched by a bug in the application code...) Interpreters and JIT compilers are much more subject to this kind of problem, particularly if they are written in C themselves. ;) There have been a few JVM exploits historically, though it is still much easier to make a secure JVM than to make tens of thousands of secure applications.
Finally, remember that even C has the burden of bugs in its compiler, runtime, and libraries, so this argument is useless at differentiating between C and safe compiled languages (unless you can argue that the latter have more complicated support code).
Yes, it could of course be prevented, like most other security holes.
Java has a bad reputation for being slow, but there are plenty of natively-compiled languages that are quite fast and would at worst result in a denial-of-service (exception) if they had this bug, never execution of arbitrary code.
It is still a wonder to me that people who claim to be concerned about security choose C for their projects.
Yes, I did. In fact I was surprised to get it, but it came.
In order to use the GPL at all, you must copyright your software. So just copyrighting it will of course not be incompatible with the GPL!
Just time-stamping it is supposed to work, although it seems that they'll grant patents for anything, regardless of prior art, these days. It might make sense to try to publish any obvious minor variations on the idea, too.
I feel the same way. However, I think that I finally do see the light at the end of the tunnel. An artist working in 320x200 VGA space can certainly make careful use of pixels to provide a much better visual result than one gets from the Quake I engine. But as resolutions increase, the difference becomes much smaller: an artist working at high resolution is essentially working with vectors rather than pixels (think of a painter or cartoonist), and so in some sense has already lost his "pixel perfect" advantage.
It also seems that we are getting so much 3D power recently that it's no longer enough to simply have dazzling numbers of alpha-transparent triangles. 3D games are needing to resort to more interesting visual styles (cf Zelda: Wind Walker), and I think that may ultimately bring them to the same artistic levels that we see in modern "2D" games like the Capcom fighters or GBA side-scrollers.
I don't really think that this deserves the status of a "myths" page, since it simply responds to catch phrases with personal opinion. Usually a myths page responds with facts.
Anyway, the author seems to be deeply confused about a number of things. The most obvious is the distinction between the creation of software (which is a real service and which cannot in any sense be "free") and the duplication of software (which, as technology increases, has increasingly more negligible costs). None but the most deranged would argue that programmers should not be paid for the services that they render, should they choose to. Of course they must be, because there is nothing special about that service. On the other hand, the ability to duplicate and share software (and other digitized works) makes them a significantly different kind of product than food and clothing. Like the author's, any argument that fails to realize this distinction is likely specious.
One can argue that it is difficult to directly compensate programmers for their service, and that selling software provides a good indirect way to compensate them. I believe this model is ultimately doomed to fail because of free(dom) software alternatives, as the author also apparently does. But because we will typically have to pay for the service of creating software, this does not threaten the livelihood of programmers (except inasmuch as it reduces inefficiency and so makes some services not needed).
The DMCA does not make reverse engineering illegal.
The relevant sections are about copyright, not reverse engineering.
You could theoretically substitute hash-cash for real cash, but you still need an escrow system to do sender-risks.
Yes, this is what I said at the end. But when you look at it like this you suddenly realize that it is the power of the escrow agency that makes the ABM scheme work. The beauty of "sender pays" systems like hash cash is that no such thing is required.
This is an interesting theoretical design. I don't see why to put it into practice, though. "Hash Cash" accomplishes the same thing without using real money, and real money is dangerous because it's a lot more desirable than CPU time (what about iloveyou.vbs sending out high-bond e-mails to a special collection account? This is not a feature we can trust the average user to have enabled.) It also requires much more sophisticated machinery in place, like certificate authorities. (Of course, if we wanted to, we could also use certificate authorities to do post-hoc hash cash bonds. But if the algorithms can avoid certificate authorities, that is much better!)