An ISPs profit margins are directly tied to usage. The more bandwidth the sell that goes unused, the higher their margins. So, it a very real sense music sharing is hurting ISP bottom-lines.
But, that's not why they're victims. They're victims because it is impossible to give someone an Internet pipe and yet not allow them to abuse it. You can start censoring content, but that's a slippery slope, and you'll soon find thta you cannot handle the arms race. What exactly are these ISPs to do? Business hounds them, the government hounds them and other subscribers (who are not sharing music) hound them over lack of bandwith at the neighborhood level (because their neighbors are sucking it dry).
They're at a loss, and honestly doing all they can to stay ahead of the game.
It's kind of like saying that people who maintain highways are accomplices in illegal racing. They're not. They're in fact suffering the extra cost of maintenance and safety because of it.
On the other hand, having many options and then letting them weed themselves out over time has proven to be a useful model for preserving flexibility and innovation.
GNOME, KDE, Window Maker, etc are all as good as they are at what they do exactly because there is choice. Take that away, and you would have xterm+uwm.
For those who don't understand this distinction: glib is *not* a GNOME library. It is used by GNOME, but it's actually part of the Gtk+ project.
In glib2, the object model used in Gtk+ and GNOME was broken in half and all of the non-GUI parts were put into glib, but that's really just a small part of glib. It also provides a number of invaluable tools for C programming, acting as a sort of extension to the standard libc, and providing many of the facilities that higher level languages generally give you.
Most high level languages already do most of what glib does, and in those higher-level language bindings to Gtk+ and GNOME (e.g. from Python, Perl or Ruby) the glib interface is just a matter of data-type conversion and synchronization of assumptions (e.g. how exceptions will be handled).
Ok, understand that what you're unhappy about is having to write OO code in a language that doesn't do OO.
That's fine. You don't have to like it.
That's no reflection on GObject or the design of Gtk+ and GNOME. If you don't want to write such code, don't. If you would rather write C++, Python, Perl, Ruby or Scheme, then please feel free. These are all well-supported languages in GNOME and Gtk+. In fact, the C++ binding (called gtkmm) is arguably cleaner than most native C++ object models because of the fact that the object model *needed* to be that clean to be usable in C!
Check out the latest gtkmm and/or the Python bindings if you want to manage a GObject in a language that provides OO tools. If you prefer C, then check out the C interface. THAT is why GNOME and Gtk+ are so popular, and enjoy such a wide-spread support in the industry (in fact, Sun's decision to use GNOME was primarily based on the fact that it was *not* a C++-based system, and they had some ABI problems at the time, which are since moot).
That's a good benchmark, but it's not all-inclusive. Many books do not use ISBN, though they are all in some sort of niche. I would say that somewhere around 99% of books use it, and everything that you would find at B&N or Wordsworth, etc.
I think the original poster was more asking why the article makes it sound like the ISP was being treated as an accomplice rather than a secondary victim. The ISP may have evidence, but showing up and demanding the evidence is different from showing up and "raiding" the ISP (which implies either that the ISP did not cooperate or that they were not given the option).
Usually, in the US, any individual or institution that was caught up in such a fray would be served with court documents. After that, they would be asked to produce the evidence required in the form required without delay or interference. That's not what we call a "raid".
In fact, the U.S. the Department of the Treasury (in the form of the Secret Service) has been seriously slapped down by the courts for performing "raids" against individuals (e.g. an ex-coworker of mine) and organizations (e.g. Steve Jackson Games) who ran buliten board systems (BBSs) in Texas in the late 80s. They essentially treated every BBS that a criminal had used as an accomplice, rather than simply serving them with subpoenas where the had probable cause to believe there was evidence to be had.
The "Operation Sundevil" case as it was known, was fraught with other problems (e.g. the SS had overstepped it's bounds), but you get the general idea. SJG was almost put out of business by this raid, and that's just not reasonable. They had no complicity in the crime, and ended up a victim only because of the investigation even though they attempted to cooperate.
If that's what happened in this case in Australia, I think the ISPs should sue the government for their damages. It's simply not fair or reasonable that organizations that attempt to (or would be willing to) cooperate are harmed by the investigation of another party.
I would argue that your "joe sixpack" is not generally of "average intelligence" and "average education".
Given such a person, yes you should be able to explain quantum computing or knot theory or elliptic curves. It may take you months, but the question is ultimately: do you realy know it well enough to say it, or are there points where your knowledge is build on undefined macros?
True story: I followed that link, and I'm reading this on my laptop, so I had to tilt my screen a bit to see the image clearly!;-)
I've been following OLED for a fairly long while not. It's a really nice technology and a huge step forward. For those who want the really fast run-down, the benefits are: no back-light so contrast and display life and power usage are far better; no polarizing filters so angle of viewing is much better; and because the material produces its own light, the range of color is astoundingly rich.
Down sides: It's still a transistor-per-pixel technology; there are complexities in the manufacturing; no on yet knows how to build them reliably for large-scale displays.
If you can't explain something in ordinary words to a layman, then you really don't understand it.
You went on a great length to explain why your field of study acts as a disproof for this, but I think you wrapped it up neatly in a bow and proved the point.
If you cannot take an average joe (that is to say, someone with at least an average intelligence, retention, education, etc) and explain to them exactly what it is that you know, then you don't really know it.
You might *think* you know it, but ultimately, if you cannot say it, you don't know it.
I know some things in my field (programming) that I would have a very hard time explaining to someone who had not done an awful lot of programming. Those things, interestingly enough, are the things that I consider myself to be a "knowledgable ametuer" in regard to. Encryption is a good example. I know a heck of a lot more about encryption than a giant fraction of the population (guessing that it's well over 99%). However, I could not explain to a lay person how RSA works. I could explain it to someone else who knows cryptography, but I would be cheating. I would skip over chunks of the explanation in a short-hand that both of us would understand and take as written, as there are many references that explain the rest of the details.
Most spammers don't use open relays, and they don't use their ISP's mail server!
Do you have any facts or specific experience to back this up, or are you talking out of your ass?
I feel like I should make some kind of snide comment to balance yours, but it's not really necessary.
Your experiences have biased you, so while your criticism of the original poster's lack of facts to back up his claim is justified, you fall into pretty much the same trap.
If you had worked for a company that focused more on maintaining a DNSRBL rather than maintaining a user-bsae of mostly residential users, you might have had a very different outlook. What's more if you had worked for a Russian ISP you might have had a VERY different outlook.
I'm not supporting the original assertion or countering it. I'm just saying that your statements were effectively null.
The right way to measure would be to set up a honey pot for spam and record all of the senders' IP addresses. Then you would have to go back and try to determine how many of those were open relays vs. active attackers.
I suspect you'll find that the majority of "clueless spammers" are sending through relays, but the ones that are really making a business out of it are just cycling through ISP after ISP, and sending directly. I base this hypothisis on discussions with people in the business, so I have yet a third set of biases.... Anyone want to do the testing?
any Linux distribution would qualify as `UNIX' to most lay definitions
I would think that most lay definitions would involve either "licensee of the trademarked term", -- which would include one and only one Linux distribution that I know of: Caldera -- or "descended from the original UNIX source".
UNIX(r) is not a specific OS, but a trademark. There are many implementations of the OS that originated the trademark, and even a few international standards based on it. The major OSes that descend directly from the original code base are: Solaris, UnixWare, HP/UX, FreeBSD, OpenBSD, NetBSD and BSDi (which has mostly merged with FreeBSD, AFAIK).
Non-UNIX(r) OSes that conform to much of the formal and informal conventions of the platform (e.g. the POSIX and X/Open standards) include Linux and HURD.
I've generally refered to these as UNIX-like OSes.
I was only replying to what was stated, and while I was thinking about the binary!=source problem in more depth, I was not going to muddy the waters.
However, since you started it...;-)
It should be easy enough to write a tool that verifies heuristically that a given chunk of machine code is at least very likely to be the result of a given chunk of source code. If you wrote such a tool, you should be able to run that over the binaries and the source together and kick out the areas of the code flagged as having the lowest corrolation. You still have to do manual comparison against the dissassembled source, but the work-load will have been cut down temendously.
There are both ways to thwart this technique and ways to thwart the thwarting. At some point, you really must have a human look at the entire thing, and even then, well-hidden flaws in the source can be just as damning as flaws put in after-the-fact.
But I would be happy with the results of such a tool if it proved itself in a fairly large number of practical tests against known changes.
How would this tool work? Well, one way that you could go for C, C++ and the like is to look at the source by removing all alpha-numerics and then determining what the general flow of the resulting machine code should look like. For example, you know that,
{(){();.();};}
is likely to have a certain sort of signature in the resulting output. If it has a wildly different signature (e.g. there are more branches than you expect or the stack is changed more often than you expect), you can zero in on those differences and classify them. In some cases, you will have to learn to identify a particular compiler's inlining and constant-folding techniques, but again if you're not looking for exact matches, the problem is much easier. Loop-unrolling is another easy technique to spot.
You start with a tool that's good at detecting changes in un-optimized code and then slowly tweak it for the case of optimization.
You missed the original poster's point. He was asking what happens if China gets the source, but cannot verify that the binaries that they were given (e.g. the shrink-wrapped version) is based on this source-code or something else (e.g. this with some special calls to MSNSAWeakenSSLKeySpace(true)).
Ultimately, if China cannot reproduce the binaries from the source, they will probably have to dismiss this as a marketting stunt.
There's not much too ask. The BSA is the enforcement arm of a business model that is dying. They should be slowly legislated out of existance where possible and otherwise ignored until dead.
Angel deserves poor ratings this season. Not because it's poorly written (far from it!) or acted (some good some bad, just like Buffy), but because the air-heads at the network decided to put it up against the best written show on television (IMHO), The West Wing. I know for a fact that I'm not the only person who likes both shows.
I have a TiVo, so I set up the West Wing to record only new episodes and Angel to record all showings. Hopefully they'll get smart and re-run the entire season before the next one starts....
Ok, get your BSD flamethrowers ready (the FreeBSD ports folks will recognize why in a sec), but I'm firmly of the opinion that Perl should include a full PDL tree with the language.
Perl + PDL is perhaps the strongest argument I've ever seen for using high-level languages such as Perl. However, distribution vendors seem intent on keeping this wonderful tool out of their distributions by default, and leaving the integration of its various dependancies up to the users (CPAN does a good job of this for most modules, but PDL depends on several libraries and program suites external to Perl like g77 and Mesa).
It's time to admit that PDL is a package which is as valuable and worth having as Perl itself for everything from simple matrix operations to analysis of time-series data to image data manipulation to rendering visualization and far, far more....
But then, perhaps I'm just wierd because I feel the same way about DBI, libwww-perl and Parse::RecDescent.
These are not simply libraries, but the tools which make Perl what it is. Failing to install them is like failing to install libc with a C compliler and saying, "heck, you've got crt0.o; you can link; what's your problem?!"
First off, you need to understand what that error means. It's saying that your shell (bash) was told by the operating system (the exec(2) system call in one of its many forms, probably execvp(2)) that the program you requested execution for was not valid (e.g. it had a bad "magic number" in the UNIX world or association under Windows or resource fork under MacOS).
Clearly he attempted to run this program on a platform which did not support it (guessing UNIX or Linux).
However, there's nothing wrong with running this test from bash (assuming that it's a Windows test and not a DOS-based direct access test which is a safe bet for anything designed to test DirectX9 performance). There are very nice ports of bash to Windows including the one from Cygnus (included in their cygwin package).
What one might also try is:
wine./3dmark2003.exe
which would be an interesting test of Wine's DirectX support. I'm guessing WineX would be the only thing that could even get close to running this puppy, and even then I don't think WineX has DX9 support yet. Please chime in if you know, as I'm too lazy to check out the WineX site;-)
To paraphrase your (implied) point in a somewhat geeky way:
s/software/guns/
I disagree. It actually doesn't matter what I think of gun control, the statement is still wrong.
It *would* be accurate if someone were writing open source missile guidance systems. In that case, you could agrue that you might want a missile guidance system for personal use either as a hobbiest (e.g. for model rocketry) or for hunting purposes (ok, that last one is meant to be funny, but you get the idea).
In fact, that argument currently does not fly in the U.S. You are simply not allowed to put a guidance system on any rocket without very special case permission from the military, which means that model rocketry types cannot make rockets that compensate for conditions, takeoff-and-land, etc.
However, if you're writing an OS, that's more like designing metal shop tools. Yes, those tools can be used to make guns, but I would disagree that we should restrict access to metal shop tools or that those who build them need concern themselves with how they are used. There is a level at which a tool is just a tool, and its function is not "dangerous enough" to restrict the freedom of making or using that tool.
Where you draw that line is, of course, a matter of debate, and you would be better off rhetorically focusing on that rather than specious search-and-replace arguments.
However, OpenSSH uses OpenSSL to do its encryption. For this reason OpenSSH may (or may not) be vulnerable. Thus, you should probably take steps to prevent the attack even if it turns out that it was not possible to exploit the hole for OpenSSH.
That means you have to a) upgrade OpenSSL b) use a non-block cipher or c) check host keys manually.
Like I said, it probably will not matter unless you are using SSH to do something that happens often (like a cron-job that runs an ssh-based rsync every few minutes or fetchmail-IMAP-via-ssh) since the attack needs many data points in order to succede.
The concern was not that they had modified the code or docs, but the copyright messages. You are not allowed to simply re-assign copyright to yourself (under US and international copyright law).
This has nothing to do with licensing at all. You could put the code under the GPL, MPL, or any of MS EULA for Office, and you would still have the same problem. The only time you can take a work and assign copyright to yourself is if that work is in the Public Domain, which of course means that it has no copyright at all.
[NOTE: This post assumes you use a UNIX or UNIX-like system and OpenSSH]
For those of you who are concerned that ssh may be vulnerable (I don't know... it probably won't matter unless you have an automatic process like rsync or fetchmail using ssh to re-connect over and over on a regular basis), you can use "arcfour" as the "Cipher" parameter in openssh. To force this, create a ".ssh/config" file in your home directory with these lines in it:
Ciphers arcfour Protocol 2
arcfour is known to have security problems with protocol version one, so it's not supported there (or was not last I looked, but that was a Changelog entry from 20000509).
Yep, I got that. I was responding seriously because it shows people who don't understand cryptography how truly abstract this gets.
Yes, what you were saying was funny (the fist time someone said it to me about 10 years ago), but it's also a serious consideration. "f(P) = replace P with unrelated P'" is a valid cryptographic technique which is used in many places and even more important outside of cryptography. It's just not encryption in the strictest sense. This tends to blow most people away (it did for me) when first learning about crypto and considering the scope of what it means to transform data.
As for the flaw in enigma, you correctly state the larger case. I was abbreviating wildly, and there are many caveats and pitfalls that I did not go into. Saying "E(P) != P" is an oversimplification that I intended only to get the point across.
What you suggest is actually a valid obfuscation techinque, and sometimes obfuscation is what you want, not encryption. Encryption has a definition:
[paraphrased by memory from Applied Cryptography] any
E() such that there exists a D() such that D(E(P))=P for some (usually any) plaintext P; though presumably you also want to ensure that E(P)!=P or your E() isn't very secure!
You will note that your technique connot be defined as encryption, since it is not reversable. There are other cryptographic techniques which are not reversable, but which have interesting properties. Hashes are a great example. A hash is difficult to reverse (actally almost all hashing schemes are impossible to reverse perfectly as they map to multiple plaintexts), but because it reduces a large plaintext domain to a smaller domain of hashes, it can be used for such activities as digital signatures, key verification (e.g. password checks) and many other cryptographic and non-cryptographic activities.
Problem (1) is addressed by the randomness RFC, and good implementations of this technique can be found in such places as/dev/random implementations on most UNIX-like systems, most high-level programming languages' core libraries, etc.
Yes, a cheap sound-card is a great source of entropy. But, as pointed out in the randomness RFC (still too lazy to go find the number, but google "randomness rfc", and I'm sure you'll find it) you need to cull your entropy pool to remove signal. Every programming language that can do any kind of real math has an FFT available, and if you understand what such a transform does, you're pretty much set there.
The real problem is guarding your randomness. Quantum transmission of the key is a security nightmare. It's security through obscurity through physics, and I for one am not willing to bank QM won't undergo a radical change in the next 5 years that teaches us how to access these keys in transit. Worse, I'm not willing to bank on the idea that some government won't find such a technique and forget to send me the memo telling me that my data is now wide open.
But, even if you accept that QM provides for perfect key transmission, you have to be able to get that key to a device that can transmit it and back from the device that can recieve it. Both of these steps are obvious places to attack the system. Granted, it avoids the problem of someone putting a listening device under your trans-atlantic cable, but does nothing for the myriad of other ways that the key could be stolen.
All that asside, I just wanted to point out that the article is total bunk. It pretty much reads like a dozen other press releases I've seen on the topic of proprietary encryption techniques. It makes wild claims about the value of key-size without any context to support them (why is 1 million bits of key better than 256 bits? what is the key being used for? Is it an xor pad? Is it a symetic keypair?) Please ignore such lame attempts at salesmanship, and let real science prevail over crap.
Slashdot Mirror
An ISPs profit margins are directly tied to usage. The more bandwidth the sell that goes unused, the higher their margins. So, it a very real sense music sharing is hurting ISP bottom-lines.
But, that's not why they're victims. They're victims because it is impossible to give someone an Internet pipe and yet not allow them to abuse it. You can start censoring content, but that's a slippery slope, and you'll soon find thta you cannot handle the arms race. What exactly are these ISPs to do? Business hounds them, the government hounds them and other subscribers (who are not sharing music) hound them over lack of bandwith at the neighborhood level (because their neighbors are sucking it dry).
They're at a loss, and honestly doing all they can to stay ahead of the game.
It's kind of like saying that people who maintain highways are accomplices in illegal racing. They're not. They're in fact suffering the extra cost of maintenance and safety because of it.
On the other hand, having many options and then letting them weed themselves out over time has proven to be a useful model for preserving flexibility and innovation.
GNOME, KDE, Window Maker, etc are all as good as they are at what they do exactly because there is choice. Take that away, and you would have xterm+uwm.
For those who don't understand this distinction: glib is *not* a GNOME library. It is used by GNOME, but it's actually part of the Gtk+ project.
In glib2, the object model used in Gtk+ and GNOME was broken in half and all of the non-GUI parts were put into glib, but that's really just a small part of glib. It also provides a number of invaluable tools for C programming, acting as a sort of extension to the standard libc, and providing many of the facilities that higher level languages generally give you.
Most high level languages already do most of what glib does, and in those higher-level language bindings to Gtk+ and GNOME (e.g. from Python, Perl or Ruby) the glib interface is just a matter of data-type conversion and synchronization of assumptions (e.g. how exceptions will be handled).
Ok, understand that what you're unhappy about is having to write OO code in a language that doesn't do OO.
That's fine. You don't have to like it.
That's no reflection on GObject or the design of Gtk+ and GNOME. If you don't want to write such code, don't. If you would rather write C++, Python, Perl, Ruby or Scheme, then please feel free. These are all well-supported languages in GNOME and Gtk+. In fact, the C++ binding (called gtkmm) is arguably cleaner than most native C++ object models because of the fact that the object model *needed* to be that clean to be usable in C!
Check out the latest gtkmm and/or the Python bindings if you want to manage a GObject in a language that provides OO tools. If you prefer C, then check out the C interface. THAT is why GNOME and Gtk+ are so popular, and enjoy such a wide-spread support in the industry (in fact, Sun's decision to use GNOME was primarily based on the fact that it was *not* a C++-based system, and they had some ABI problems at the time, which are since moot).
That's a good benchmark, but it's not all-inclusive. Many books do not use ISBN, though they are all in some sort of niche. I would say that somewhere around 99% of books use it, and everything that you would find at B&N or Wordsworth, etc.
Good start.
I think the original poster was more asking why the article makes it sound like the ISP was being treated as an accomplice rather than a secondary victim. The ISP may have evidence, but showing up and demanding the evidence is different from showing up and "raiding" the ISP (which implies either that the ISP did not cooperate or that they were not given the option).
Usually, in the US, any individual or institution that was caught up in such a fray would be served with court documents. After that, they would be asked to produce the evidence required in the form required without delay or interference. That's not what we call a "raid".
In fact, the U.S. the Department of the Treasury (in the form of the Secret Service) has been seriously slapped down by the courts for performing "raids" against individuals (e.g. an ex-coworker of mine) and organizations (e.g. Steve Jackson Games) who ran buliten board systems (BBSs) in Texas in the late 80s. They essentially treated every BBS that a criminal had used as an accomplice, rather than simply serving them with subpoenas where the had probable cause to believe there was evidence to be had.
The "Operation Sundevil" case as it was known, was fraught with other problems (e.g. the SS had overstepped it's bounds), but you get the general idea. SJG was almost put out of business by this raid, and that's just not reasonable. They had no complicity in the crime, and ended up a victim only because of the investigation even though they attempted to cooperate.
If that's what happened in this case in Australia, I think the ISPs should sue the government for their damages. It's simply not fair or reasonable that organizations that attempt to (or would be willing to) cooperate are harmed by the investigation of another party.
I would argue that your "joe sixpack" is not generally of "average intelligence" and "average education".
Given such a person, yes you should be able to explain quantum computing or knot theory or elliptic curves. It may take you months, but the question is ultimately: do you realy know it well enough to say it, or are there points where your knowledge is build on undefined macros?
Nope. Wasn't saying that at all.
I was saying that his comments about being able to describe (but at great length) what he does, means that he *can* do so.
True story: I followed that link, and I'm reading this on my laptop, so I had to tilt my screen a bit to see the image clearly! ;-)
I've been following OLED for a fairly long while not. It's a really nice technology and a huge step forward. For those who want the really fast run-down, the benefits are: no back-light so contrast and display life and power usage are far better; no polarizing filters so angle of viewing is much better; and because the material produces its own light, the range of color is astoundingly rich.
Down sides: It's still a transistor-per-pixel technology; there are complexities in the manufacturing; no on yet knows how to build them reliably for large-scale displays.
We shall see....
If you can't explain something in ordinary words to a layman, then you really don't understand it.
You went on a great length to explain why your field of study acts as a disproof for this, but I think you wrapped it up neatly in a bow and proved the point.
If you cannot take an average joe (that is to say, someone with at least an average intelligence, retention, education, etc) and explain to them exactly what it is that you know, then you don't really know it.
You might *think* you know it, but ultimately, if you cannot say it, you don't know it.
I know some things in my field (programming) that I would have a very hard time explaining to someone who had not done an awful lot of programming. Those things, interestingly enough, are the things that I consider myself to be a "knowledgable ametuer" in regard to. Encryption is a good example. I know a heck of a lot more about encryption than a giant fraction of the population (guessing that it's well over 99%). However, I could not explain to a lay person how RSA works. I could explain it to someone else who knows cryptography, but I would be cheating. I would skip over chunks of the explanation in a short-hand that both of us would understand and take as written, as there are many references that explain the rest of the details.
any Linux distribution would qualify as `UNIX' to most lay definitions
I would think that most lay definitions would involve either "licensee of the trademarked term", -- which would include one and only one Linux distribution that I know of: Caldera -- or "descended from the original UNIX source".
UNIX(r) is not a specific OS, but a trademark. There are many implementations of the OS that originated the trademark, and even a few international standards based on it. The major OSes that descend directly from the original code base are: Solaris, UnixWare, HP/UX, FreeBSD, OpenBSD, NetBSD and BSDi (which has mostly merged with FreeBSD, AFAIK).
Non-UNIX(r) OSes that conform to much of the formal and informal conventions of the platform (e.g. the POSIX and X/Open standards) include Linux and HURD.
I've generally refered to these as UNIX-like OSes.
I was only replying to what was stated, and while I was thinking about the binary!=source problem in more depth, I was not going to muddy the waters.
However, since you started it...
It should be easy enough to write a tool that verifies heuristically that a given chunk of machine code is at least very likely to be the result of a given chunk of source code. If you wrote such a tool, you should be able to run that over the binaries and the source together and kick out the areas of the code flagged as having the lowest corrolation. You still have to do manual comparison against the dissassembled source, but the work-load will have been cut down temendously.
There are both ways to thwart this technique and ways to thwart the thwarting. At some point, you really must have a human look at the entire thing, and even then, well-hidden flaws in the source can be just as damning as flaws put in after-the-fact.
But I would be happy with the results of such a tool if it proved itself in a fairly large number of practical tests against known changes.
How would this tool work? Well, one way that you could go for C, C++ and the like is to look at the source by removing all alpha-numerics and then determining what the general flow of the resulting machine code should look like. For example, you know that, is likely to have a certain sort of signature in the resulting output. If it has a wildly different signature (e.g. there are more branches than you expect or the stack is changed more often than you expect), you can zero in on those differences and classify them. In some cases, you will have to learn to identify a particular compiler's inlining and constant-folding techniques, but again if you're not looking for exact matches, the problem is much easier. Loop-unrolling is another easy technique to spot.
You start with a tool that's good at detecting changes in un-optimized code and then slowly tweak it for the case of optimization.
You missed the original poster's point. He was asking what happens if China gets the source, but cannot verify that the binaries that they were given (e.g. the shrink-wrapped version) is based on this source-code or something else (e.g. this with some special calls to MSNSAWeakenSSLKeySpace(true)).
Ultimately, if China cannot reproduce the binaries from the source, they will probably have to dismiss this as a marketting stunt.
There's not much too ask. The BSA is the enforcement arm of a business model that is dying. They should be slowly legislated out of existance where possible and otherwise ignored until dead.
Angel deserves poor ratings this season. Not because it's poorly written (far from it!) or acted (some good some bad, just like Buffy), but because the air-heads at the network decided to put it up against the best written show on television (IMHO), The West Wing. I know for a fact that I'm not the only person who likes both shows.
I have a TiVo, so I set up the West Wing to record only new episodes and Angel to record all showings. Hopefully they'll get smart and re-run the entire season before the next one starts....
Ok, get your BSD flamethrowers ready (the FreeBSD ports folks will recognize why in a sec), but I'm firmly of the opinion that Perl should include a full PDL tree with the language.
Perl + PDL is perhaps the strongest argument I've ever seen for using high-level languages such as Perl. However, distribution vendors seem intent on keeping this wonderful tool out of their distributions by default, and leaving the integration of its various dependancies up to the users (CPAN does a good job of this for most modules, but PDL depends on several libraries and program suites external to Perl like g77 and Mesa).
It's time to admit that PDL is a package which is as valuable and worth having as Perl itself for everything from simple matrix operations to analysis of time-series data to image data manipulation to rendering visualization and far, far more....
But then, perhaps I'm just wierd because I feel the same way about DBI, libwww-perl and Parse::RecDescent.
These are not simply libraries, but the tools which make Perl what it is. Failing to install them is like failing to install libc with a C compliler and saying, "heck, you've got crt0.o; you can link; what's your problem?!"
Clearly he attempted to run this program on a platform which did not support it (guessing UNIX or Linux).
However, there's nothing wrong with running this test from bash (assuming that it's a Windows test and not a DOS-based direct access test which is a safe bet for anything designed to test DirectX9 performance). There are very nice ports of bash to Windows including the one from Cygnus (included in their cygwin package).
What one might also try is:which would be an interesting test of Wine's DirectX support. I'm guessing WineX would be the only thing that could even get close to running this puppy, and even then I don't think WineX has DX9 support yet. Please chime in if you know, as I'm too lazy to check out the WineX site
It *would* be accurate if someone were writing open source missile guidance systems. In that case, you could agrue that you might want a missile guidance system for personal use either as a hobbiest (e.g. for model rocketry) or for hunting purposes (ok, that last one is meant to be funny, but you get the idea).
In fact, that argument currently does not fly in the U.S. You are simply not allowed to put a guidance system on any rocket without very special case permission from the military, which means that model rocketry types cannot make rockets that compensate for conditions, takeoff-and-land, etc.
However, if you're writing an OS, that's more like designing metal shop tools. Yes, those tools can be used to make guns, but I would disagree that we should restrict access to metal shop tools or that those who build them need concern themselves with how they are used. There is a level at which a tool is just a tool, and its function is not "dangerous enough" to restrict the freedom of making or using that tool.
Where you draw that line is, of course, a matter of debate, and you would be better off rhetorically focusing on that rather than specious search-and-replace arguments.
Yes, you are correct. ssh != ssl
However, OpenSSH uses OpenSSL to do its encryption. For this reason OpenSSH may (or may not) be vulnerable. Thus, you should probably take steps to prevent the attack even if it turns out that it was not possible to exploit the hole for OpenSSH.
That means you have to a) upgrade OpenSSL b) use a non-block cipher or c) check host keys manually.
Like I said, it probably will not matter unless you are using SSH to do something that happens often (like a cron-job that runs an ssh-based rsync every few minutes or fetchmail-IMAP-via-ssh) since the attack needs many data points in order to succede.
The concern was not that they had modified the code or docs, but the copyright messages. You are not allowed to simply re-assign copyright to yourself (under US and international copyright law).
This has nothing to do with licensing at all. You could put the code under the GPL, MPL, or any of MS EULA for Office, and you would still have the same problem. The only time you can take a work and assign copyright to yourself is if that work is in the Public Domain, which of course means that it has no copyright at all.
For those of you who are concerned that ssh may be vulnerable (I don't know... it probably won't matter unless you have an automatic process like rsync or fetchmail using ssh to re-connect over and over on a regular basis), you can use "arcfour" as the "Cipher" parameter in openssh. To force this, create a ".ssh/config" file in your home directory with these lines in it:arcfour is known to have security problems with protocol version one, so it's not supported there (or was not last I looked, but that was a Changelog entry from 20000509).
Good luck.
Correct, my technique should be defined as humor
Yep, I got that. I was responding seriously because it shows people who don't understand cryptography how truly abstract this gets.
Yes, what you were saying was funny (the fist time someone said it to me about 10 years ago), but it's also a serious consideration. "f(P) = replace P with unrelated P'" is a valid cryptographic technique which is used in many places and even more important outside of cryptography. It's just not encryption in the strictest sense. This tends to blow most people away (it did for me) when first learning about crypto and considering the scope of what it means to transform data.
As for the flaw in enigma, you correctly state the larger case. I was abbreviating wildly, and there are many caveats and pitfalls that I did not go into. Saying "E(P) != P" is an oversimplification that I intended only to get the point across.
Hope this helps!
Problem (1) is addressed by the randomness RFC, and good implementations of this technique can be found in such places as /dev/random implementations on most UNIX-like systems, most high-level programming languages' core libraries, etc.
Yes, a cheap sound-card is a great source of entropy. But, as pointed out in the randomness RFC (still too lazy to go find the number, but google "randomness rfc", and I'm sure you'll find it) you need to cull your entropy pool to remove signal. Every programming language that can do any kind of real math has an FFT available, and if you understand what such a transform does, you're pretty much set there.
The real problem is guarding your randomness. Quantum transmission of the key is a security nightmare. It's security through obscurity through physics, and I for one am not willing to bank QM won't undergo a radical change in the next 5 years that teaches us how to access these keys in transit. Worse, I'm not willing to bank on the idea that some government won't find such a technique and forget to send me the memo telling me that my data is now wide open.
But, even if you accept that QM provides for perfect key transmission, you have to be able to get that key to a device that can transmit it and back from the device that can recieve it. Both of these steps are obvious places to attack the system. Granted, it avoids the problem of someone putting a listening device under your trans-atlantic cable, but does nothing for the myriad of other ways that the key could be stolen.
All that asside, I just wanted to point out that the article is total bunk. It pretty much reads like a dozen other press releases I've seen on the topic of proprietary encryption techniques. It makes wild claims about the value of key-size without any context to support them (why is 1 million bits of key better than 256 bits? what is the key being used for? Is it an xor pad? Is it a symetic keypair?) Please ignore such lame attempts at salesmanship, and let real science prevail over crap.