Re:One of the reasons the markets went down
on
Tech Stocks Tumble
·
· Score: 2
I think you should write a book on the interactions between short term intrabank lending interest rate target policy and equity market fluctuations. Really, I mean your thesis is soooo original that I'm sure that millions of lemmings, err, I mean investors, will buy your work and you'll make a ton of money. Sarcasm aside, the increase in the CPI is miminal and considerably below long term trend lines. In all probability, it represents the higher energy prices caused by the supply deficit in petroleum products. The Fed usually does not consider the CPI as a major precusor of real inflation; as an indicator, it is rather insensitive and tends to be lagging, rather than leading. The CPI is one of many factors that are considered, ranging from PPI to margin percentages to structural unemployment indexes. Even if the Fed were to raise interest rates, as they have done so repeatedly in the past, it is unreasonable to project causation vis a vis the fall in stock prices into what may be correlation. Not to mention that recently the market has not reacted strongly to interest rate changes (so there goes correlation as well)...
Ummm, don't you see the truth already? Slashdot probably gets about 500 submissions a day. Of those, 400 deal with the plunging tech sector stock prices, particularly VALinux and Redhat. Obviously Slashdot is never going to post those articles, despite their great interest to the open source community as a whole and open source developers in particular. Then, we have about 50 "junk" submissions dealing with random garbage. Another 20 submissions are about $NEW_VERSION of $RANDOM_OPEN_SOURCE_PACKAGE is $POSITIVE_ADJECTIVE_OF_AFFIRMATION. The Slashdot crew then discards 20 more submissions about $RANDOM_OPEN_SOURCE_PACKAGE has $ENORMOUS_SECURITY_HOLE (Sendmail, BIND!?!), leaving just 10 submissions that can be used. Two of them are paeans from prominent open-source personalities (such as ESR) as they desperately attempt to keep their fortunes from slipping away as the connected and better informed than ever market realizes how little Linux companies are really worth. Three more are about $OUTRAGE_OF_THE_WEEK, wherein some $VERY_BIG_COMPANY stomps on the perceived rights of the consumer, employee, or student; the Slashdot writers really love these, since tons of Slashdot people always write to these (yes! more ad impressions). Yet another three are about a trivial interview with some random person in another magazine or discussion forum, such that Slashdot can leech off the work of others (hmmm, sounds familiar, doesn't this?). And the last two are stories like these, dealing with topics that are years old becuase there simply isn't anything else pro-Linux or anti-Microsoft to post!!!
Thank you for expressing the position of many outraged users of this site who feel geniunely saddened at the current state of this discussion forum. Any post that does not conform to the Open Source Movement party line is instantly moderated to oblivion where no user, especially no non-logged in user (since the change in default score display setting), is likely to see it, thereby supressing dissenting opinions. Isn't the open source community supposed to be more accepting of different opinions? Shouldn't we tolerate and listen to the ideas of people that don't neccesarily agree with our own?
The free interchange of information and ideas is one of the defining foundations of this new interconnected society which many of us have worked passionately to help create and bring to fruition. I believe that we should preserve and indeed cherish differences in thought as a sign of a thriving community that can accept criticism and grow stronger through it. ESR himself once said that "One of the characteristics of healthy cultures is that they can poke fun at themselves." (quoted on www.userfriendly.com). Why is it that we are now unable to tolerate dissent? Is this hacker culture stagnating or dying?
This will be moderated down soon, so please repost this as often as possible.
Because they are not utterly irresponsible companies which have sold their souls to the imperative of a quick profit (ahem, Slashdot). They realize that acting like single-minded zealots and wantonly spreading FUD will only decrease their public image, especially when the people are bright enough to know that *there is not backdoor* worth publicizing. It's called responsible journalism and business ethics, something that CmdrTaco, ESR, and company seem to have forgotten or misplaced in their Linux IPO mania.
I've disagreed with the prevailing Slashdot conventional wisdom, so I'm going to lose massive karma because some moderator will feel the urge to supress dissenting opinions.
"cmdrtaco and crew seem to ignore all of this for some reason or another."
The reason is completely obvious. Ask yourself these three questions:
***What company did CmdrTaco first sell Slashdot to?
***What well known Linux company subsequently bought Andover?
***Is said company's stock below its IPO price?
Editorial indepedence...blah. CmdrTaco and company have sold Slashdot readers down the river for a quick profit. Corporate conscience?!?! Maybe it's Slashdot, VALinux, and Andover get on the cluetrain too. Today's markets are smarter than ever before and the individuals who participate in these markets are able to communicate with each other faster than companies can inhibit or stop this communication. You can't ignore us, you can't control us, and you can't stop us. Enjoying those millions, ESR, RobLimo, CmdrTaco, and company? Well enjoy them now, since a new revolution in information is coming and you're going to be left behind.
This has already been a well-publicized problem for the past two days. I mean, it's even on ZDNet and Cnet. Oh well, I suppose that waiting this long would mean that ESR had time to verify all of his facts.
Opps, it seems that he didn't. Anyway, the string "Netscape engineers are weenies" is indeed embedded backwards inside the referenced dll file. However, this does not allow arbitrary access to websites, nor is it some sort of hidden backdoor password. If you already have authoring permissions on a server, the dll will allow you to read the web pages of other sites that may also be hosted on the server. Essentially, the wall between theoretically independent virtual hosted sites is slightly reduced. The flaw does NOT allow one to modify content, nor does it allow one access to information that is protected by NTFS permissions instead of IIS permissions. The real use of the string is to name mangle all URL requests of a certain form before use by the Microsoft Interdev 1.0 software.
Interesting enough, the scrutiny under which this dll has been examined has revealed the existence of a *real* problem, a buffer overflow that is theoretically explotiable (I'm not sure of the details, but IIRC, it's an unlength-checked strcpy). Open-source software does help expose deliberately placed backdoors, however, it does not target the problem that caused the Microsoft flaw in the first place: untrustworthy programmers. No project, closed source or open source, run under the cathedral model or the bazaar model, can escape the fundemental concept of information security: you must place at least some implicit trust on the people who build/mantain/administer your software. Open source software allows others oversight so that they can spot this type of problem (witness the Dansie Shopping Cart backdoor), but cannot act as a magic pill that solves all problems of this nature. It is naive to believe that just making something opensource makes it inherently more difficult to include backdoors and "design for insecurity." This just reiterates and reemphasizes the need for continual code audits and scrutiny of all executable code in secure operating environments.
A single instance of the discrete logarithm problem defined in the subgroup of points on an eliptic curve over GF(2) modulo an irreducible polynomial has been broken by brute force. An incredible accomplishment really; Robert Harley describes it as the largest public key crypto crack ever and the largest distributed computation project using a nontrivially parallel algorithm. The details are fascinating, but probably only to someone interested in number theory and abstract algebra, especially how the collision search was made faster by exploiting the low class number of the overall group and how orbits of 218 points could be created using the unique Frobenius structure of the group. Nonetheless, the project is similar to a standard crack of the DES algorithm (ala d.net/Deep Crack). It doesn't expose a flaw in the eliptic curve algorithm, nor does it open the way to breaking the method used in wireless phones in a more efficient manner. Essentially, Harley's group obtained a practical data point in establishing the difficulty of breaking one ECDL problem; the Slashdot headline is very misleading. Besides, this same story was covered about a week ago on the front page, under a different "twist."
That wasn't quite my point. Open source programs constitute a minority of the SpecINT and SpecFP suites; each of the individual benchmarks is designed to be representative of the workload of a typical *scientific workstation*. Spec cares not about your 3D video card, your CD-ROM transfer rates, or your 3D sound card. There are no empty loops in the Spec benchmarks, and intruction dispatch speed is not tested as a discrete benchmark; it will factor into the overall score. As for compilers optimizating specially (via pattern matching) for Spec idioms or code fragments, all the better luck for them! If the compiler can, say, sense the standard form for DAXPY or another common Spec kernel and emit inline hand-scheduled code for the fragment, I will be all the happier, since I can use the same fragment in my code and tempt the compiler into emitting specially optimized asm (this works especially well on the good compilers: Intel's reference compiler, compaq's ccc, SGI's sgi-perflib/compiler suite). br. With regards to your comment about realistic computer usage: those tests that you suggest can be done in such a minute duration of time on any modern computer that they are _not worth testing_! It's essentially "fast enough" for any possible user; let's face it, the CEO's secretary does not need a P-III 800 or an Athlon, to say nothing of an Origin 2000, Starfire, RS/6000, or AlphaCluster.
This comment deals with scientific programming; YMMV wrt game or graphics benchmarks. I *want* compiler writers and microarchitecture designers to optimize for reasonably well-designed benchmarks, such as Spec. I *want* compilers to recognize critical code fragments, idioms, and kernels in the Spec benchmarks and emit perfectly scheduled code. I don't care if the compiler can't make the optimization in the general case; when I write scientific code, I take care to use the standard style of writing certain common transformations, such as dot products so that compilers (Compaq's ccc and SGI's compilers are excellent in this regard) that target SpecFP pattern match the code and produce good code. I want microarchitecture designers to include elements that make their chips run Spec fast, since if a benchmark in Spec runs quickly and my computational task is similar, it will most likely benefit from any architecture changes as well. Thus, selecting good benchmarks in a suite is utterly critical if the benchmark number will have any value at all; moreover, there are many incidental benefits to selecting benchmarks that represent commonly used tasks or programs.
Where do you get this from? For web server applications, I would want insane memory bandwidth, good SMP capabilities, and efficient cache handling/IO subsystems. For scientific applications, I wouldn't usually consider a x86 processor except under very specific cases, SSE or no SSE. The FP register stack just about kills parallelism and SSE only offers 32-bits of precision. I really don't want to save 3 days on computation time to spend 3 weeks using numerical analysis to hunt down pesky instabilities. To decode PPV signals, standard integer math is more than adaquate (I believe that it uses variable line-based rotations and offset phase shifting). Spec, TPC, and other benchmarks are *very* useful when buying high-end computer systems. Of course, in the end, what counts is performance on *your* application; that's why aggregate system benchmarks (WinBench 2000, etc.) are sometimes useful for home/office users who want to get a gauge for performance on typical tasks. Then again, if a user is going to be sending email or writing 2-page memos, the computer he/she is using won't matter much.
I suggest basing an open-source benchmark suite on the existing Spec benchmarks, as most of the code (or functionally equivalent code) is relatively freely available. Of the 12 SpecINT 2000 benchmarks, 5 (gzip, gcc, crafty, perlbmk, and bzip) already exist as open-source programs. The combinatorial optimization (181.mcf) benchmark's code is also on the Internet at www.zib.de, free for academic use. I'm sure someone could make a cleanroom interpretation of something similar. 175.vpr (a place and root program) can be found at http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html. 197.parser is essentially a CS student's problem about parsing and extracting strings. 252.eon is a raytracer (we can use POVRay instead). 254.gap is a general purpose math library (Victor Shoup's NTL library exercises most of the same functions). 255.vortex is a standard RDBMS; MySQL or an equivalent could be used here. 300.twolf seems rather similar to 175.vpr; as circuit designing is really far removed from my field, I'll leave this to someone else.
If the encrypted output of DES and Blowfish could be distinguished without knowledge of the key, the algorithms would be deeply flawed, since that would imply that internal structure of the algorithm was leaking into the ciphertext. A classical analogy would be the Enigma system: no letter could ever encrypt to itself, making it possible to distinguish Enigma ciphertext from random gibberish. In general, the existence of a distinguishing attack usually means that that a true attack on the underlying security of the algorithm is possible.
There are signal processing techniques (essentially a FFT, adding the encrypted data there, IFT+phase shift) that let you add information to a noisy channel such as a radio such that the transformed channel is statistically indistinguishable from a normal noisy channel as long as you don't add too much information, in a certain precise sense.
Excuse me? When did I ever state that "we should respect the authority of the robe rather than analyzing the case on the basis of its facts?" To the contrary, I suggest that we should do exactly that: analyse the circumstances of the case, rather than jumping to the knee-jerk response of saying that the law sucks or that the judge is an ignorant idiot. Civil disobedience is not to be undertaken litely, something which I believe has been forgotten in light of the urge to defy authority for its own sake, instead of for a greater purpose.
I think Signal 11 says it best in his.sig quote "Defy authority? Say's who?".
Additionally, if you have any problems with the content of my previous postings, I would be happy to hear your comments. My previous postings have usually be rather technical in nature. If I have made an inaccurate assertion, please correct me.
What should we have done if the judge had gone the other way? Precisely what we do when the judge rules for a position that we favor. One cannot selectively pick and choose which judicial mandates to ignore and which to accept based on the personal self-benefit that would be derived from such a position. I too am utterly outraged when some judge rules for some idiotic company only interested in enriching its own pockets at the expense of the consumer and trodding over the rights of the many; however, if we accept the rulings in our favor, and thereby the implicit underlying premise that our common abstract conception of justice will eventually prevail in the end through the judicial process, we would be inconsistent to refuse to obey a ruling that had gone the other way.
Civil disobedience: a term use frequently by Slashdotters in a flimsy justification for disregard of the law. It's a noble concept, but mirroring the DeCSS code, for instance, just doesn't cut it, IF you are not willing to accept responsibility for the consequences of your civil disobedience. If the judge had gone the other way, fight vigourously to have the decision overturned on appeal, pester your legislators for change in tort reform, contact all the civil liberties assocations that you know about, boycott the company, whatever. But I believe that it would certainly be hypocritical to defy such a ruling under the assertion that the judge is a moron, or some such nonsense.
This will never make it into the mainstream media. You will not see this story appear on CNN, MSNBC, or [insert your favorite news media source here]. The intial lawsuit was considered "news" and "interesting" and therefore fit for distribution becuase it would attract eyeballs and therefore ratings. But a lawsuit being dismissed?
Why, it's completely boring and uninteresting. Who would ever care about such a thing? Result=no public exposure when these ridiculous lawsuits get thrown out as they should. Chalk it up to a fundemental flaw in the media system and how it perceives its relationship to those who receive information from it. The media has no legal responsibility whatsoever for printing or distributing a retraction or correction to an inaccurate previous story. The media has no legal responsibility to present both sides of a story. The media has no legal responsibility to follow up on a story and report on its aftereffects.
Victories in the courtroom are all well and good, but when was the last time you say Bernstein, Junger, or [some ludicrous lawsuit thrown out or some issue resolved in favor of any resonable sense of justice] receiving equal prominence with, say, the RIAA or MPAA's receiving preliminary injunctions against such "pirating and hacking tools like DeCSS"?
[quasi-flame, but probably deserved]Are you on crack? I'm sorry, but I have no better way to say this. Are you crazy?
"I thought that since people basically brute-force through X numbers and run fast-fourier transforms and what-not on them we thought it would be nice if you could compress the keyspace to a pitifully small number. a 1000-bit keyspace now only has maybe 16 bits of keyspace."
Please spare us your thoughts and actually learn something about what you are blatthering about. To find large prime numbers, most people use a variant of Miller-Rabin SPPT efficiently. To enumerate all the primes in a certain interval, we use either an Atkins sieve or an appropiately blocked standard sieve. To determine the next larger prime than a certain number, we use standard sieving or delta-big delta sieving. To decompose a composite into primes, we use either the ECM ( And how precisely do you plan on compressing a 1000-bit keyspace into a 16-bit keyspace? Ever heard of the pigeonhole principle? Do you even know how many primes are in that interval? The distribution of prime numbers in a specific interval is regular in a very specific and formal way that effectively means that you can treat them as randomly distributed (yes, I know about the RH, I don't care). And how would a 10000-bit be represented as 20-bits of keyspace? Please tell me "how primes work"? I would really like to know and collect my Fields medal.
Finally, if you by some miracle got your GA working (and please don't get me started on this particular bit of idiocy; smoothness arguments about the primes and their spacing will be a waste of space), how would this render symmetric algorithms obselete? How would this magically crack DES, IDEA, or [insert block cipher here]? How would this magically crack RC4, SEAl or [insert stream cipher here]? How would this magically crack ECC, the modified-Chor-Rivest knapsack scheme, NTRU, or [insert other PK algorithm here]?
It won't, because you're talking out of your ass here.[/quasi-flame]
Wrong. If the ERH is proven correct, a variant of the classic Miller-Rabin SPPT can prove a number to be prime in strictly polynomial time. The Jacobi sum test (aka APR-CL algorithm) can prove primality in deterministic O(n^(lg lg n)) time, which is really close to polynomial. The ECPP can prove primality, under a very plausible heuristic argument about the smoothness of a certain class of eliptic curves that is too complicated to explain here, in O(n^(6+eps)) time for all numbers except a set with Lebsegue measure 0 (ie almost all integers in a well-defined, formal sense). Proving primality is in the complexity class RP, not Co-NP, via the inefficient in practice, but theoretically rigourous, Adleman-Huang algorithm (based on improvements to Goldwasser's original randomized algorithm over eliptic curves of modular genus 2) that can prove the primality of a number of any input n in running time O(n^(13)). It's also a complete pain to program (better than Atkins-Elkies-Schoof, but that's not saying much), but that's an aside. Needless to say, we don't use algorithms like these very often...
Seti@HOME has outright stated that they have no need for more processing power. Their clients are dreadfully wasteful and unoptimized. Their leadership essentially tells people who want to help with their design to fuck off and their computational cores (of which the algorithms have been known for decades) are completely closed source, unlike those of d.net.
ECC is not strictly faster than RSA. An exact comparison is rather difficult, as the proponents of each cryptosystem can adjust the parameters to make their system appear faster (ie. low or high encryption exponents, choice of basis, GF(p) or GF(2^m),optimization efforts). In most cases, RSA is faster than ECC, especially with a reasonable (2^16+1) public exponent during encryption. ECC is also NOT patent free. Certicom and others have patents on specific implementations and types of the general eliptic curve algorithm that can be significantly faster and more memory friendly than the classic eliptic curve defined over a large prime.
There are several certificational weaknesses of the DES algorithm that are not practical. Linear and differential cryptanalysis can reduce the required time needed to break DES to about 2^45, with massive amounts of known and chosen plaintext/ciphertext pairs.
Your statements about the strengths of double and triple DES should be clarified. The key-length equivalents that you mention are only applicative for what is know as a "meet in the middle" attack, whereby the attacker uses a known PT->CT pair and decrypts one DES encryption of the CT with a test key while encrypting the PT with another test key under one DES encryption. The attacker keeps a list of the pairs of the results in the middle (I'm handwaving here, as there are some optimizations that can be made) and when there is a match, the correct keys can be trivially recovered. The attack requires serious memory to even think of carrying out (orders of magnitude greater than all of the RAM installed on every computer that has ever been built).
An ECC derived primitive is used to exchange symmetric encryption keys. Not that one would even bother trying to break the PKC to attack the system; just reverse engineer the hardware and read the key off from that. Definitely not trivial, but much easier than any other way.
Predict primes?!?! What does that mean? Enumerating all the primes up to an arbitrary integer n can be done very efficiently using an Atkins sieve in minimal memory; it's usually faster to generate them than to store the all the primes under 2^32. Deciding whether an arbitrary integer is prime or composite can also be done in polynomial time (via the Adleman-Huang algorithm, or in probablistic polynomial time via the ECPPA). Simple enumerability arguments argue against the possibility that an algorithm could do this in linear time. Decomposing a composite into primes through the best known methods takes subexponential time using a *very* sophistocated algorithm. Counting the number of points on an eliptic curve also takes polynomial time using another very involved algorithm (Atkins-Elkies-Schoof). The best known technique for generating collisions on an eliptic curve takes fully exponential time (Rho sieving w/ distinguished points).
So please, tell me, what does "linear solving" entail? What does it mean to "predict primes in linear time"? What does this "deviation" refer to? How does this tree "fully 'bloom'"?
errr, I know how the Enigma was cracked. Reading comprehension skills, please? Nobody outside of the intelligence/signals community knows how the Lorentz or Purple was broken. I would be glad if I were corrected on this point with a specific citation or reference. And no, Stephenson's book is interesting, but it's only fiction. Kahn's _Codebreakers_ doesn't go into any of the gritty specifics either (sort of like the difference between _Numerical Recipies_ and Cohen's _A Course in Computational Number Theory_ or TAOCP).
Hello!?!? Have you ever implemented an algorithm for use on high performance computers (I'm not talking about dual Pentiums or Athlons here)? I sincerely don't believe so. There is no standard computational task that will have an order of magnitude improvement when coded in assembly compared with well-structured and blocked C. Please give me a specific example of such a kernel. I am honestly very curious about what algorithm is giving your compiler so much trouble. It certainly isn't a F90 intrinsic or a LAPACK kernel. Most of the VPP codes that I've used also compile nicely with a few well-placed compiler directives.
I agree with your point about specialized hardware; that's why I didn't bring it up.
Slashdot Mirror
I think you should write a book on the interactions between short term intrabank lending interest rate target policy and equity market fluctuations. Really, I mean your thesis is soooo original that I'm sure that millions of lemmings, err, I mean investors, will buy your work and you'll make a ton of money. Sarcasm aside, the increase in the CPI is miminal and considerably below long term trend lines. In all probability, it represents the higher energy prices caused by the supply deficit in petroleum products. The Fed usually does not consider the CPI as a major precusor of real inflation; as an indicator, it is rather insensitive and tends to be lagging, rather than leading. The CPI is one of many factors that are considered, ranging from PPI to margin percentages to structural unemployment indexes. Even if the Fed were to raise interest rates, as they have done so repeatedly in the past, it is unreasonable to project causation vis a vis the fall in stock prices into what may be correlation. Not to mention that recently the market has not reacted strongly to interest rate changes (so there goes correlation as well)...
Ummm, don't you see the truth already? Slashdot probably gets about 500 submissions a day. Of those, 400 deal with the plunging tech sector stock prices, particularly VALinux and Redhat. Obviously Slashdot is never going to post those articles, despite their great interest to the open source community as a whole and open source developers in particular. Then, we have about 50 "junk" submissions dealing with random garbage. Another 20 submissions are about $NEW_VERSION of $RANDOM_OPEN_SOURCE_PACKAGE is $POSITIVE_ADJECTIVE_OF_AFFIRMATION. The Slashdot crew then discards 20 more submissions about $RANDOM_OPEN_SOURCE_PACKAGE has $ENORMOUS_SECURITY_HOLE (Sendmail, BIND!?!), leaving just 10 submissions that can be used. Two of them are paeans from prominent open-source personalities (such as ESR) as they desperately attempt to keep their fortunes from slipping away as the connected and better informed than ever market realizes how little Linux companies are really worth. Three more are about $OUTRAGE_OF_THE_WEEK, wherein some $VERY_BIG_COMPANY stomps on the perceived rights of the consumer, employee, or student; the Slashdot writers really love these, since tons of Slashdot people always write to these (yes! more ad impressions). Yet another three are about a trivial interview with some random person in another magazine or discussion forum, such that Slashdot can leech off the work of others (hmmm, sounds familiar, doesn't this?). And the last two are stories like these, dealing with topics that are years old becuase there simply isn't anything else pro-Linux or anti-Microsoft to post!!!
Thank you for expressing the position of many outraged users of this site who feel geniunely saddened at the current state of this discussion forum. Any post that does not conform to the Open Source Movement party line is instantly moderated to oblivion where no user, especially no non-logged in user (since the change in default score display setting), is likely to see it, thereby supressing dissenting opinions. Isn't the open source community supposed to be more accepting of different opinions? Shouldn't we tolerate and listen to the ideas of people that don't neccesarily agree with our own?
The free interchange of information and ideas is one of the defining foundations of this new interconnected society which many of us have worked passionately to help create and bring to fruition. I believe that we should preserve and indeed cherish differences in thought as a sign of a thriving community that can accept criticism and grow stronger through it. ESR himself once said that "One of the characteristics of healthy cultures is that they can poke fun at themselves." (quoted on www.userfriendly.com). Why is it that we are now unable to tolerate dissent? Is this hacker culture stagnating or dying?
This will be moderated down soon, so please repost this as often as possible.
Because they are not utterly irresponsible companies which have sold their souls to the imperative of a quick profit (ahem, Slashdot). They realize that acting like single-minded zealots and wantonly spreading FUD will only decrease their public image, especially when the people are bright enough to know that *there is not backdoor* worth publicizing. It's called responsible journalism and business ethics, something that CmdrTaco, ESR, and company seem to have forgotten or misplaced in their Linux IPO mania.
I've disagreed with the prevailing Slashdot conventional wisdom, so I'm going to lose massive karma because some moderator will feel the urge to supress dissenting opinions.
"cmdrtaco and crew seem to ignore all of this for some reason or another."
The reason is completely obvious. Ask yourself these three questions:
***What company did CmdrTaco first sell Slashdot to?
***What well known Linux company subsequently bought Andover?
***Is said company's stock below its IPO price?
Editorial indepedence...blah. CmdrTaco and company have sold Slashdot readers down the river for a quick profit. Corporate conscience?!?! Maybe it's Slashdot, VALinux, and Andover get on the cluetrain too. Today's markets are smarter than ever before and the individuals who participate in these markets are able to communicate with each other faster than companies can inhibit or stop this communication. You can't ignore us, you can't control us, and you can't stop us. Enjoying those millions, ESR, RobLimo, CmdrTaco, and company? Well enjoy them now, since a new revolution in information is coming and you're going to be left behind.
This has already been a well-publicized problem for the past two days. I mean, it's even on ZDNet and Cnet. Oh well, I suppose that waiting this long would mean that ESR had time to verify all of his facts.
Opps, it seems that he didn't. Anyway, the string "Netscape engineers are weenies" is indeed embedded backwards inside the referenced dll file. However, this does not allow arbitrary access to websites, nor is it some sort of hidden backdoor password. If you already have authoring permissions on a server, the dll will allow you to read the web pages of other sites that may also be hosted on the server. Essentially, the wall between theoretically independent virtual hosted sites is slightly reduced. The flaw does NOT allow one to modify content, nor does it allow one access to information that is protected by NTFS permissions instead of IIS permissions. The real use of the string is to name mangle all URL requests of a certain form before use by the Microsoft Interdev 1.0 software.
Interesting enough, the scrutiny under which this dll has been examined has revealed the existence of a *real* problem, a buffer overflow that is theoretically explotiable (I'm not sure of the details, but IIRC, it's an unlength-checked strcpy). Open-source software does help expose deliberately placed backdoors, however, it does not target the problem that caused the Microsoft flaw in the first place: untrustworthy programmers. No project, closed source or open source, run under the cathedral model or the bazaar model, can escape the fundemental concept of information security: you must place at least some implicit trust on the people who build/mantain/administer your software. Open source software allows others oversight so that they can spot this type of problem (witness the Dansie Shopping Cart backdoor), but cannot act as a magic pill that solves all problems of this nature. It is naive to believe that just making something opensource makes it inherently more difficult to include backdoors and "design for insecurity." This just reiterates and reemphasizes the need for continual code audits and scrutiny of all executable code in secure operating environments.
A single instance of the discrete logarithm problem defined in the subgroup of points on an eliptic curve over GF(2) modulo an irreducible polynomial has been broken by brute force. An incredible accomplishment really; Robert Harley describes it as the largest public key crypto crack ever and the largest distributed computation project using a nontrivially parallel algorithm. The details are fascinating, but probably only to someone interested in number theory and abstract algebra, especially how the collision search was made faster by exploiting the low class number of the overall group and how orbits of 218 points could be created using the unique Frobenius structure of the group. Nonetheless, the project is similar to a standard crack of the DES algorithm (ala d.net/Deep Crack). It doesn't expose a flaw in the eliptic curve algorithm, nor does it open the way to breaking the method used in wireless phones in a more efficient manner. Essentially, Harley's group obtained a practical data point in establishing the difficulty of breaking one ECDL problem; the Slashdot headline is very misleading. Besides, this same story was covered about a week ago on the front page, under a different "twist."
That wasn't quite my point. Open source programs constitute a minority of the SpecINT and SpecFP suites; each of the individual benchmarks is designed to be representative of the workload of a typical *scientific workstation*. Spec cares not about your 3D video card, your CD-ROM transfer rates, or your 3D sound card. There are no empty loops in the Spec benchmarks, and intruction dispatch speed is not tested as a discrete benchmark; it will factor into the overall score. As for compilers optimizating specially (via pattern matching) for Spec idioms or code fragments, all the better luck for them! If the compiler can, say, sense the standard form for DAXPY or another common Spec kernel and emit inline hand-scheduled code for the fragment, I will be all the happier, since I can use the same fragment in my code and tempt the compiler into emitting specially optimized asm (this works especially well on the good compilers: Intel's reference compiler, compaq's ccc, SGI's sgi-perflib/compiler suite).
br. With regards to your comment about realistic computer usage: those tests that you suggest can be done in such a minute duration of time on any modern computer that they are _not worth testing_! It's essentially "fast enough" for any possible user; let's face it, the CEO's secretary does not need a P-III 800 or an Athlon, to say nothing of an Origin 2000, Starfire, RS/6000, or AlphaCluster.
This comment deals with scientific programming; YMMV wrt game or graphics benchmarks.
I *want* compiler writers and microarchitecture designers to optimize for reasonably well-designed benchmarks, such as Spec. I *want* compilers to recognize critical code fragments, idioms, and kernels in the Spec benchmarks and emit perfectly scheduled code. I don't care if the compiler can't make the optimization in the general case; when I write scientific code, I take care to use the standard style of writing certain common transformations, such as dot products so that compilers (Compaq's ccc and SGI's compilers are excellent in this regard) that target SpecFP pattern match the code and produce good code. I want microarchitecture designers to include elements that make their chips run Spec fast, since if a benchmark in Spec runs quickly and my computational task is similar, it will most likely benefit from any architecture changes as well. Thus, selecting good benchmarks in a suite is utterly critical if the benchmark number will have any value at all; moreover, there are many incidental benefits to selecting benchmarks that represent commonly used tasks or programs.
Where do you get this from? For web server applications, I would want insane memory bandwidth, good SMP capabilities, and efficient cache handling/IO subsystems. For scientific applications, I wouldn't usually consider a x86 processor except under very specific cases, SSE or no SSE. The FP register stack just about kills parallelism and SSE only offers 32-bits of precision. I really don't want to save 3 days on computation time to spend 3 weeks using numerical analysis to hunt down pesky instabilities. To decode PPV signals, standard integer math is more than adaquate (I believe that it uses variable line-based rotations and offset phase shifting). Spec, TPC, and other benchmarks are *very* useful when buying high-end computer systems. Of course, in the end, what counts is performance on *your* application; that's why aggregate system benchmarks (WinBench 2000, etc.) are sometimes useful for home/office users who want to get a gauge for performance on typical tasks. Then again, if a user is going to be sending email or writing 2-page memos, the computer he/she is using won't matter much.
I suggest basing an open-source benchmark suite on the existing Spec benchmarks, as most of the code (or functionally equivalent code) is relatively freely available. Of the 12 SpecINT 2000 benchmarks, 5 (gzip, gcc, crafty, perlbmk, and bzip) already exist as open-source programs. The combinatorial optimization (181.mcf) benchmark's code is also on the Internet at www.zib.de, free for academic use. I'm sure someone could make a cleanroom interpretation of something similar. 175.vpr (a place and root program) can be found at http://www.eecg.toronto.edu/~vaughn/vpr/vpr.html. 197.parser is essentially a CS student's problem about parsing and extracting strings. 252.eon is a raytracer (we can use POVRay instead). 254.gap is a general purpose math library (Victor Shoup's NTL library exercises most of the same functions). 255.vortex is a standard RDBMS; MySQL or an equivalent could be used here. 300.twolf seems rather similar to 175.vpr; as circuit designing is really far removed from my field, I'll leave this to someone else.
If the encrypted output of DES and Blowfish could be distinguished without knowledge of the key, the algorithms would be deeply flawed, since that would imply that internal structure of the algorithm was leaking into the ciphertext. A classical analogy would be the Enigma system: no letter could ever encrypt to itself, making it possible to distinguish Enigma ciphertext from random gibberish. In general, the existence of a distinguishing attack usually means that that a true attack on the underlying security of the algorithm is possible.
There are signal processing techniques (essentially a FFT, adding the encrypted data there, IFT+phase shift) that let you add information to a noisy channel such as a radio such that the transformed channel is statistically indistinguishable from a normal noisy channel as long as you don't add too much information, in a certain precise sense.
Excuse me? When did I ever state that "we should respect the authority of the robe rather than analyzing the case on the basis of its facts?" To the contrary, I suggest that we should do exactly that: analyse the circumstances of the case, rather than jumping to the knee-jerk response of saying that the law sucks or that the judge is an ignorant idiot. Civil disobedience is not to be undertaken litely, something which I believe has been forgotten in light of the urge to defy authority for its own sake, instead of for a greater purpose.
.sig quote "Defy authority? Say's who?".
I think Signal 11 says it best in his
Additionally, if you have any problems with the content of my previous postings, I would be happy to hear your comments. My previous postings have usually be rather technical in nature. If I have made an inaccurate assertion, please correct me.
What should we have done if the judge had gone the other way? Precisely what we do when the judge rules for a position that we favor. One cannot selectively pick and choose which judicial mandates to ignore and which to accept based on the personal self-benefit that would be derived from such a position. I too am utterly outraged when some judge rules for some idiotic company only interested in enriching its own pockets at the expense of the consumer and trodding over the rights of the many; however, if we accept the rulings in our favor, and thereby the implicit underlying premise that our common abstract conception of justice will eventually prevail in the end through the judicial process, we would be inconsistent to refuse to obey a ruling that had gone the other way.
Civil disobedience: a term use frequently by Slashdotters in a flimsy justification for disregard of the law. It's a noble concept, but mirroring the DeCSS code, for instance, just doesn't cut it, IF you are not willing to accept responsibility for the consequences of your civil disobedience. If the judge had gone the other way, fight vigourously to have the decision overturned on appeal, pester your legislators for change in tort reform, contact all the civil liberties assocations that you know about, boycott the company, whatever. But I believe that it would certainly be hypocritical to defy such a ruling under the assertion that the judge is a moron, or some such nonsense.
This will never make it into the mainstream media. You will not see this story appear on CNN, MSNBC, or [insert your favorite news media source here]. The intial lawsuit was considered "news" and "interesting" and therefore fit for distribution becuase it would attract eyeballs and therefore ratings. But a lawsuit being dismissed?
Why, it's completely boring and uninteresting. Who would ever care about such a thing? Result=no public exposure when these ridiculous lawsuits get thrown out as they should. Chalk it up to a fundemental flaw in the media system and how it perceives its relationship to those who receive information from it. The media has no legal responsibility whatsoever for printing or distributing a retraction or correction to an inaccurate previous story. The media has no legal responsibility to present both sides of a story. The media has no legal responsibility to follow up on a story and report on its aftereffects.
Victories in the courtroom are all well and good, but when was the last time you say Bernstein, Junger, or [some ludicrous lawsuit thrown out or some issue resolved in favor of any resonable sense of justice] receiving equal prominence with, say, the RIAA or MPAA's receiving preliminary injunctions against such "pirating and hacking tools like DeCSS"?
[quasi-flame, but probably deserved]Are you on crack? I'm sorry, but I have no better way to say this. Are you crazy?
"I thought that since people basically brute-force through X numbers and run fast-fourier transforms and what-not on them we thought it would be nice if you could compress the keyspace to a pitifully small number. a 1000-bit keyspace now only has maybe 16 bits of keyspace."
Please spare us your thoughts and actually learn something about what you are blatthering about. To find large prime numbers, most people use a variant of Miller-Rabin SPPT efficiently. To enumerate all the primes in a certain interval, we use either an Atkins sieve or an appropiately blocked standard sieve. To determine the next larger prime than a certain number, we use standard sieving or delta-big delta sieving. To decompose a composite into primes, we use either the ECM (
And how precisely do you plan on compressing a 1000-bit keyspace into a 16-bit keyspace? Ever heard of the pigeonhole principle? Do you even know how many primes are in that interval? The distribution of prime numbers in a specific interval is regular in a very specific and formal way that effectively means that you can treat them as randomly distributed (yes, I know about the RH, I don't care). And how would a 10000-bit be represented as 20-bits of keyspace? Please tell me "how primes work"? I would really like to know and collect my Fields medal.
Finally, if you by some miracle got your GA working (and please don't get me started on this particular bit of idiocy; smoothness arguments about the primes and their spacing will be a waste of space), how would this render symmetric algorithms obselete? How would this magically crack DES, IDEA, or [insert block cipher here]? How would this magically crack RC4, SEAl or [insert stream cipher here]? How would this magically crack ECC, the modified-Chor-Rivest knapsack scheme, NTRU, or [insert other PK algorithm here]?
It won't, because you're talking out of your ass here.[/quasi-flame]
Wrong. If the ERH is proven correct, a variant of the classic Miller-Rabin SPPT can prove a number to be prime in strictly polynomial time. The Jacobi sum test (aka APR-CL algorithm) can prove primality in deterministic O(n^(lg lg n)) time, which is really close to polynomial. The ECPP can prove primality, under a very plausible heuristic argument about the smoothness of a certain class of eliptic curves that is too complicated to explain here, in O(n^(6+eps)) time for all numbers except a set with Lebsegue measure 0 (ie almost all integers in a well-defined, formal sense). Proving primality is in the complexity class RP, not Co-NP, via the inefficient in practice, but theoretically rigourous, Adleman-Huang algorithm (based on improvements to Goldwasser's original randomized algorithm over eliptic curves of modular genus 2) that can prove the primality of a number of any input n in running time O(n^(13)). It's also a complete pain to program (better than Atkins-Elkies-Schoof, but that's not saying much), but that's an aside. Needless to say, we don't use algorithms like these very often...
Seti@HOME has outright stated that they have no need for more processing power. Their clients are dreadfully wasteful and unoptimized. Their leadership essentially tells people who want to help with their design to fuck off and their computational cores (of which the algorithms have been known for decades) are completely closed source, unlike those of d.net.
ECC is not strictly faster than RSA. An exact comparison is rather difficult, as the proponents of each cryptosystem can adjust the parameters to make their system appear faster (ie. low or high encryption exponents, choice of basis, GF(p) or GF(2^m),optimization efforts). In most cases, RSA is faster than ECC, especially with a reasonable (2^16+1) public exponent during encryption. ECC is also NOT patent free. Certicom and others have patents on specific implementations and types of the general eliptic curve algorithm that can be significantly faster and more memory friendly than the classic eliptic curve defined over a large prime.
There are several certificational weaknesses of the DES algorithm that are not practical. Linear and differential cryptanalysis can reduce the required time needed to break DES to about 2^45, with massive amounts of known and chosen plaintext/ciphertext pairs.
Your statements about the strengths of double and triple DES should be clarified. The key-length equivalents that you mention are only applicative for what is know as a "meet in the middle" attack, whereby the attacker uses a known PT->CT pair and decrypts one DES encryption of the CT with a test key while encrypting the PT with another test key under one DES encryption. The attacker keeps a list of the pairs of the results in the middle (I'm handwaving here, as there are some optimizations that can be made) and when there is a match, the correct keys can be trivially recovered. The attack requires serious memory to even think of carrying out (orders of magnitude greater than all of the RAM installed on every computer that has ever been built).
An ECC derived primitive is used to exchange symmetric encryption keys. Not that one would even bother trying to break the PKC to attack the system; just reverse engineer the hardware and read the key off from that. Definitely not trivial, but much easier than any other way.
Predict primes?!?! What does that mean? Enumerating all the primes up to an arbitrary integer n can be done very efficiently using an Atkins sieve in minimal memory; it's usually faster to generate them than to store the all the primes under 2^32. Deciding whether an arbitrary integer is prime or composite can also be done in polynomial time (via the Adleman-Huang algorithm, or in probablistic polynomial time via the ECPPA). Simple enumerability arguments argue against the possibility that an algorithm could do this in linear time. Decomposing a composite into primes through the best known methods takes subexponential time using a *very* sophistocated algorithm. Counting the number of points on an eliptic curve also takes polynomial time using another very involved algorithm (Atkins-Elkies-Schoof). The best known technique for generating collisions on an eliptic curve takes fully exponential time (Rho sieving w/ distinguished points).
So please, tell me, what does "linear solving" entail? What does it mean to "predict primes in linear time"? What does this "deviation" refer to? How does this tree "fully 'bloom'"?
errr, I know how the Enigma was cracked. Reading comprehension skills, please? Nobody outside of the intelligence/signals community knows how the Lorentz or Purple was broken. I would be glad if I were corrected on this point with a specific citation or reference. And no, Stephenson's book is interesting, but it's only fiction. Kahn's _Codebreakers_ doesn't go into any of the gritty specifics either (sort of like the difference between _Numerical Recipies_ and Cohen's _A Course in Computational Number Theory_ or TAOCP).
Hello!?!? Have you ever implemented an algorithm for use on high performance computers (I'm not talking about dual Pentiums or Athlons here)? I sincerely don't believe so. There is no standard computational task that will have an order of magnitude improvement when coded in assembly compared with well-structured and blocked C. Please give me a specific example of such a kernel. I am honestly very curious about what algorithm is giving your compiler so much trouble. It certainly isn't a F90 intrinsic or a LAPACK kernel. Most of the VPP codes that I've used also compile nicely with a few well-placed compiler directives.
I agree with your point about specialized hardware; that's why I didn't bring it up.