I am not being sarcastic when I say this would great news if the patent were issued. We all know the patent system is deeply flawed, as is our current conception of intellectual property. What better way to change the system by issuing patents so idiotic and encompassing that every large multinational company in the world will have its legal teams working to break the patent, or better yet, to lobby to have the entire system changed and overhauled.
If you insist on imagining words that do not exist in my posting, I don't think it's productive for me to continue to reply substantively. If people set thresholds high enough that people with much older computers are not willing to tolerate such a high delay, it is their choice to do so. Subnetworks form all of the time even today. Even today, if you are running off of a 14.4 dialup, I wouldn't expect many people to be sharing files with you. The computational burden threshold can be set low enough that (does some back of the hand calculations) a 386 running at 25 Mhz will incur at most a half second delay, while still preventing a top of the line spam machine from responding to more than a couple dozen queries at the same time. I submit that it is better to take proactive measures against spammers, who will certainly ruin the Gnutella system for *all* of its users, that may have the negative consequence of reducing, but not totally eliminating, the worth of the system to a small minority of its users.
Your rebuttal derives from a misunderstanding of the protocol that I proposed. Every user selects their own threshold for how much work they want others to have to do before their *own* client will choose to display results. In turn any user receiving a request can set a threshold for how much work they choose to do in computing collisions; if the user decides that computing a 19-bit collision would take too long on his/her computer, the program would simply drop the request. The argument that different servers could be routed through is true, but irrelevant: the primary filtering will occur on the client that has sent the query and intervening servers (if any) may choose to ignore the hash cash if they choose (although this would result in slightly lower utilization efficiency, in that if intervening servers *did* check the hash cash to meet *their own* threshold, blatantly obvious spam could be dropped immediately). The scheme is based that if enough proportion of people set reasonable thresholds (that they decide personally is sufficient for imposing a great enough cost of spammers while only causing a reasonable delay for other users), it will develop an immune system of sorts against mass spam, whose senders would find it impossible to do the computations that would meet the general threshold standards. The system is in fact rather easy to implement; I might consider writing the patch myself and submitting it in a week or so.
Hash cash (no, it's not paying for access through the distribution of drugs). Basically, it is a way of ensuring that the server receiving and acting on a request must spend a certain amount of time computing some function of the input in order to be able to send information back. This normally would not bother a typical user who would only need to respond to requests that match a real file if you set the delay to something like a tenth of a second on a normal computer in use today. The amount of work that needs to be done could be increased to keep up with the growth in speed of computers.
A possible protocol based on hashing:
*Each client selects a random nonce constructed by appending n bits to a representation of the current time in seconds, as well as a header describing how much hash cash would be needed for a valid response.
*Any software receiving the query would be required to construct say x different collisions on the first y-bits of the hash of the nonce, with the input restricted to appending more information to the random nonce.
*If the original client does not a receive a reply containing valid, distinct units of hash cash, the client silently discards the information and places the offending IP on a blocklist. The original client keeps track of the last m units of hash cash to prevent duplicates.
*Each client may set its own threshold for how much hash cash will be needed for a valid reply. Responding clients may choose not to respond if it decides that too much hash cash would be needed.
There are many other alternatives that offer even more control over how much work would be required.
There are certainly stream ciphers that use shift register still in use today. They're wonderfully suited to very fast hardware implementation, have an enormous body of theoretical research supporting them, and take up almost no space at all. Even so, they would not be in violation of the patent.
It's quite simple really; Apple doesn't have and doesn't need to have a valid legal basis to file a lawsuit against the operators of the websites. Their objective is not to win or to recover damages; most such frivolous lawsuits are dismissed. Rather, they seek to stifle public discourse for economic benefit. More generally, this is known as a SLAPP (Strategic Lawsuit Against Public Participation). Normally, SLAPPs are brought by companies against protest groups, individuals, or public interest lobbyists on matters such as environment concerns, real estate developement, and zoning regulations. By transforming what is essentially public debate on issues of wide-ranging concern in a protected public forum into a legal discussion on the *effects* of the debate on the issue, rather than on the issue at hand. Luckily, you can protect yourself by some simple steps:
-Expressing yourself in a Q-forum (quintessentially public forum) such as a newspaper
-Make sure that your statements of fact are true
-Seek legal advice *before* taking action that may result in a SLAPP
-Move to California or another state with an anti-SLAPP law:-)
Did you read "Oddly enough, cryptoanalytical and cryptographic secrets are *explicitly exempt* from this automatic declassification system. Moreover, it's probably quite likely that de/reclassification efforts rank rather low among the NSA priorities. It's entirely possible that they simply never got around to it until now."?
BTW, 1933 wasn't in wartime. And the M-134-C represented quite a breakthrough in cryptographic technology at the time. (ObMod) And the moderators are obviously on crack.
You can read the patent for yourself at http://www.patents.ibm.com/details?&pn=US06097812_ _&s_all=1 complete with cross-references. In my opinion, the reason that best explains why the patent has just been issued now is that back in 1933 when Friedman filed for the patent, the information was immediately classified for a set period of time as a matter of course. The FOIA and related executive orders have mandated automatic declassification after 50 years unless it can be demonstrated that disclosure would have a directly detrimental effected on national security. Oddly enough, cryptoanalytical and cryptographic secrets are *explicitly exempt* from this automatic declassification system. Moreover, it's probably quite likely that de/reclassification efforts rank rather low among the NSA priorities. It's entirely possible that they simply never got around to it until now.
Now for the more speculative reason. The academic/civilian cryptographic research community has never successfully developed a general method for cryptanlysing rotor machines; basically, the limits of what we know how to break is the Enigma with knowledge of the rotor wirings and the SIGABA/ECM systems with knowledge of their rotor wirings. True, there have been vague descriptions of the cryptanalysis of Purple, but the key steps (ie. reconstruction of wirings, and far more importantly, determination of the general structure of the machine without obtaining it) have never been declassified. Rotor machines were very commonplace until about the early sixties; moreover, their descendants, shift register based stream ciphers were probably in use to this day. It's pretty safe to say that there are entire categories of cryptanalytic and cipher design techniques that we are ignorant about.
The sci.crypt newsgroup has a long thread about the patent which can be read, among other places, at http://www.remarq.com/read/cryptsci/q_RGaGOxKZQUC- -Jw#LR.
I want to address the issues in [*], [**], and [+] in a bit of greater detail. The issue of whether RSA is computationally equivalent to the IFP is considerably more up in the air than you imply. The exponents on low exponent RSA and the recent results on the distinguishibility of non-quadratic residues under certain conditions of smoothness for the numbers offset by a small integer from factors of the modulus give me pause on whether the above equivalence is true. It may well be true for the vast majority of RSA moduli. An efficient solution to the DLP *in the case where one operates modulo a composite n*, NOT in GF(p), implies that one can factor composites of the form n. 3DES is the algorithm that I would *trust* the most, but I do not believe that it is the strongest or best designed cipher in common use today; there have been many advances in cryptoanalytic techniques since DES as exemplified by an algorithm like CAST-128.
The algorithms that PGP uses with reasonable length keys are almost certainly not breakable by the NSA in trivial lengths of time (I am not discussing the actual implementation used by any specific version of PGP). The "programmer"'s quote establishes that he or she is obviously incompetent and probably does not work for any defense-related contractor. Jon Katz's use of the quote reveals that he is clueless, but we all suspected that already.
Hash function: PGP in its latest incarnations uses SHA-1, RIPEMD-160, and MD5 in that order of preference. SHA-1 was designed by the NSA and is almost unanamously regarded as the best public hash function today. The expansion function makes it very difficult to control and restrict bit changes within the hash function itself. Even if the NSA were able to create arbitrary collisions on SHA-1, this would not affect the security of the encryption algorithms, only the signature component of PGP. RIPEMD-160 seems reasonably designed; MD5 has serious weaknesses in its compression function. Luckily, almost nobody uses these two hash functions anymore.
Symmetric algorithms: A brute force attack on any encryption algorithm with prudently chosen keylengths (>128 bits) is impossible today and for the forseable future, even with customized hardware. The NSA has cryptanalytic techniques, even decades old, that the academic cryptographic community has not yet discovered. To give some trivial examples, let's look at double transposition, codes, and rotor machines. Even today, the analytic techniques used for the solution of double transposition (without multiple anagramming or known plaintext) were redacted from Friedman's Military Cryptanalytics. The state of linguistic and textual analysis is far more developed in military cryptanalysis circles; centuries of code reconstruction have seen to that. Moreover, the details of attacking advanced rotor machines (essentially anything more sophistocated than the Enigma/Hagelin machines) are still classified. The NSA has shown an ability to design algorithms so fragile that they apparently have precisely the strength they were designed for (visit Skipjack). Nonetheless, if the NSA can break academic algorithms (such as CAST, 3DES, and IDEA), they would be wise to avoid disclosing this fact on something as insignificant as a non-national security related criminal investigation.
Public key algorithms: Without QC, it's impossible that a 1024-bit RSA key will be factored using current algorithms. Even if an extension to GNFS that reduces the hueristic complexity to that of SNFS, 1024-bit RSA keys would require a large enough matrix reduction step that there is probably not enough memory in existence in the world today to do it (even with Balanced Block Lanzcos). It would even be more difficult for the DL problem; the matrix step would require entries to be mod p, rather than mod 2.
I can also think of dual Celerons, dual Pentium 3s, and MP Xeons available today, with the first two at much lower prices than the Apple desktops (with comparable, if not greater performance). So what?
If you won't be reaccessing the data, WTF do you want it polluting even a small part of the the cache hierarchy. The main memory bottleneck will always be present for 1) initial accesses and 2) accesses out of cache. The only solutions are 1) making the cache larger, 2) better algorithms and blocking, or 3) interleaved main memory.
The Itanium has been tapped out; they're working primarily on QC/V and most importantly of all, ramping up clock speed and refining the fab masks. It's an astonishing complex design to verify, but regardless of my opinion of Intel's ISA design teams, their chip designers are among the best in the industry and their verification is equally good (even considering the F00F bug and the floating point SRT errata). Intel will not release a chip as important as the first member of the IA-64 ISA without ensuring that it is functions according to specifications for the especially critical reason that application programers will be using the Itanium to design the first generation of IA-64 compiled applications, applications whose reliability foremost and speed next will be critical to the acceptance of the IA-64 ISA as a force in the HPC market. They simply MUST get it right if they hope to follow their roadmap (Intel and HP have at least half a dozen IA-64 design teams working on the next generation chips) with any credibility. Itanium is basically do or die for Intel; McKinley will come at least half a year and by then the damage to IA-64's reputation may be too much to repair. You can always improve performance, but not if there are no applications for the ISA because no programmer or user wants to deal with processor bugs.
Does absolutely everything have to do with Microsoft? Microsoft does not want to be solely dependent on Intel chips anymore than Intel wants to be tied to Microsoft operating systems.
There are *many* problems with the IA-64 ISA and the specific Itanium implementation of it. I know someone working for HP (the organization that I work for purchases high performance supercomputers on pretty much a regular basis), who reliably states that the SpecFP performance of the Itanium is will be not at all competitive even with today's high end chips *even if it were at the same clock speed*, which it will not. They're barely pushing 700 Mhz even on small scale lots with a hell of a lot more QC than on any production fab.
Intel's moving back of the projected in-volume ship dates for the Itanium is far more important than the release, in limited OEM quantities no less, of an incremental increase in speed grade for the current generation x86 chips. Itanium, as the first line of IA-64 systems, represents the unveiling of a multi-billion dollar gamble by Intel (and its strategic, quasi-partner HP) in making inroads into the high end, 64-bit processor market. IA-64 is an elephantine archetecture; it includes everything including the kitchen sink, the waste disposal, the plumbing, and the hot water heater. It's such an unwieldy ISA for an idea that was supposed to simplify the processor by effectively exposing processor functional units to programmer visible namespace. And yet, Itanium has 10 pipeline stages (3 more than the Alpha 21264, I must add), is barely pushing 500 Mhz, and will probably be slower on a clock for clock basis than the current Alphas and PA-RISCs. I don't buy the ISA, the implementation of the ISA embodied in the Itanium, the projected performance of the Itanium (although I do have greater hopes for HP's Ft. Collins team in the McKinley...it would be hard to see how they could screw up as badly), and the market placement of the initial IA-64 processor line. All in all, I'm not exactly surprised at this delay.
Maybe this means that Intel will have some sense and wait for HP's processor team to finish design so that they can fab the McKinley and avoid embarassment.
C was based on B, which was designed almost entirely by a single person. K&R literally wrote the book on the pre-ANSI C language. C89 codified most of original C. C99 represents only minor changes to the specification of the language (restrict, long longs, and implicit casts to UDTs in actual parameters being the more important changes). C++ was designed by Stroustroup, but unfortunately the committee made some elephantine changes to the language. STL and namespaces is about the only good things, IMHO, that came out of standardization. The latest ISO C++ standard has certain flaws (limits on access of friends, among other things) that I think severely degrade the usefulness of the language.
I have no specific reason to disbelieve that the person you spoke with did in fact used to administer a Cray supercomputer. He may well be correct that certain precautions were neccesary to handle difficulties that arose when components of the machine caught on fire. What I do have problems with were the blatant inaccuracies and panic-mongering in your original comment (production of HF vapor upon ignition of Fluorinert would cause death within thirty seconds). I have no problem with you personally (I just picked this user name as a joke; you can see the comments I've posted in the past to see), just with the content of your post. If I did seem to have a bone to pick with you as a person, I do apologize for that.
You know, that's really a surprise, not using thermos to transport LN since the glass will shatter. I wonder what Dewer bottles are? Oh, that's right, glorified thermos with a reflective coating to prevent heat via radiation transport. Glass will not shatter when cooled to very low temperatures IF you don't do anything stupid with the thermos bottle, such as dropping it on the ground. Not even a liquid-hazmat-transport container will save you from your self (such as leaving one on the trunk of a car, putting said car in reverse, and running over said container). So what do you suggest, in your infinite wisdom, to transport LN? You've eliminated glass and plastic. Presumably, you would suggest transport containers made of metal. [sarcasm]That should solve everything!!![/sarcasm]
I've addressed your issue about thermal decomposition toxicity in another comment. Fluorinert has a rather low viscosity, but this does not affect its volitility, vapor pressure, or molecular weight (which are what determine the tendency of the vapor to diffuse out of confined spaces). For your information, since you seem to be so concerned, here are the relavent figures (looked up in a MSDS three rooms down):
Boiling point: 215 C VP: 42 mmHg @ 20 C Vapor density: 14x air Evaporation rate: 1.7 (Butyl acetate=1) Viscosity: 14 centistroke @ 20 C
Where do you come up with this crap? When you karam whore, you might as well try to get your facts right instead of fooling moderators into (+1 Informative) with garbage.
It is not enough for the Fluorinert to catch on fire or be next to a fire. What one does have to worry about is thermal decomposition; this will require extreme heat (according to the Material Safety Data Sheets, on the order of 1400 degrees). For comparison, a paper/wood fire burns at most about 700 degrees even with a significant fuel source and a CPU (the "Cray" that you allude to in your garbage anecdote) will not even be able to function with junction temperatures even close to a thousand degrees. You will not achieve thermal decomposition short of heating the Fluorinert on a laboratory burner or sticking molten metal into a beaker of the stuff. You must really misuse and torture the stuff to get anywhere near that point.
Moreover, what you really have to worry about is perfluoroisobutylene instead of hydrogen fluoride vapor. HF's thresehold long term tolerability is about 3ppm and it's LD50 is a lot higher than this. It will take more than 1 breath at any conceivably acheivable concentration to kill you. In any case, even a lethal dose will take more than 30 second to take effect upon intial contact or exposure (I've seen toxicity figures of about 10 minutes for exposure to hydrocyanic acid vapor, significantly more lethal than HF). Perfluoroisobutylene, on the other hand, will inhibit oxygen uptake by selectively binding with the -heme analogues in red blood cells much more efficiently.
Basic summary: Signal 11 is talking out of his ass again. You can mostly ignore his dramatics (but please consult your materials handling and safety staff if you plan to use Fluorinert) if you exercise reasonable prudence and care in using Fluorinert. "EXTREME CAUTION" is not neccesary, in the sense if one were handling certain organic mercury compounds or some other fluorine/chlorine compounds. Oh, and the oxygen masks: they're there so that any person unfortunate to be stuck in the machine room and who cannot reach the hold-off switch will not sufficate from oxygen displacement, not for poisoning (which would require a directed positive pressure system, instead of a mere supplementary oxygen mask).
You are correct; I had forgoten about implied type specifiers. For the purists out there, the last publicly available draft can be read at http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n84 3.htm. Its dated August 3, 1998, but there are no major differences between this draft and the final C99 standard. It is on pages 107-108 of the draft and pages 114-116 of the final standard.
The "spliting the 64-bit core into two x86 32-bit cores" idea could not possibly work efficiently. It is quite safe to say that the AMD folks must have come to their senses by now and abandoned any thought of doing Sledgehammer that way. A modern chip trace (say an adder) is highly optimized for the word size and rely critically on signal propagation delay for the most efficiency. Spliting (using the previous example of an adder) into 2 32-bit adders would result in totally incorrect results or a nonoptimal implementation, at which point one is better off just designing the functional units seperately.
x86 *is* a terrible ISA and backwards compatibility *does* hold back tech, both in terms of performance and price/performance. If we were not shackled with the x86 ISA so pervasively, the design and fabrication talent that Intel and AMD so obviously possess could have been far better used to design chips whose performance would have been incredible. My reasoning is that if one is willing to go so such lengths and create a new ISA (albeit one that is supposedly compatible with x86 and that extends it), thereby requirely new compilers and OS support, one should go all the way and just start from scratch and use a decent, sane, reasonable ISA.
I already do use Alphas. What really bothers me is that the fab techniques and capacity (not to mention the design teams) could be far more productively used to create chips based on a reasonable ISA. An Alpha, with the design funding of an Intel or AMD, combined with their wonderful fabs would be awe-inspiring and would bring true supercomputing level performance (at a much more reasonable price, comparable to current x86 chip prices) to the desktop, in addition to being much more pleasant to code for.
Slashdot Mirror
I am not being sarcastic when I say this would great news if the patent were issued. We all know the patent system is deeply flawed, as is our current conception of intellectual property. What better way to change the system by issuing patents so idiotic and encompassing that every large multinational company in the world will have its legal teams working to break the patent, or better yet, to lobby to have the entire system changed and overhauled.
Search for the cutils package (I know it's in Debian), specifically obfusc and unloop. GPL and all that, makes code practically unreadable.
If you insist on imagining words that do not exist in my posting, I don't think it's productive for me to continue to reply substantively. If people set thresholds high enough that people with much older computers are not willing to tolerate such a high delay, it is their choice to do so. Subnetworks form all of the time even today. Even today, if you are running off of a 14.4 dialup, I wouldn't expect many people to be sharing files with you. The computational burden threshold can be set low enough that (does some back of the hand calculations) a 386 running at 25 Mhz will incur at most a half second delay, while still preventing a top of the line spam machine from responding to more than a couple dozen queries at the same time. I submit that it is better to take proactive measures against spammers, who will certainly ruin the Gnutella system for *all* of its users, that may have the negative consequence of reducing, but not totally eliminating, the worth of the system to a small minority of its users.
Your rebuttal derives from a misunderstanding of the protocol that I proposed. Every user selects their own threshold for how much work they want others to have to do before their *own* client will choose to display results. In turn any user receiving a request can set a threshold for how much work they choose to do in computing collisions; if the user decides that computing a 19-bit collision would take too long on his/her computer, the program would simply drop the request. The argument that different servers could be routed through is true, but irrelevant: the primary filtering will occur on the client that has sent the query and intervening servers (if any) may choose to ignore the hash cash if they choose (although this would result in slightly lower utilization efficiency, in that if intervening servers *did* check the hash cash to meet *their own* threshold, blatantly obvious spam could be dropped immediately). The scheme is based that if enough proportion of people set reasonable thresholds (that they decide personally is sufficient for imposing a great enough cost of spammers while only causing a reasonable delay for other users), it will develop an immune system of sorts against mass spam, whose senders would find it impossible to do the computations that would meet the general threshold standards. The system is in fact rather easy to implement; I might consider writing the patch myself and submitting it in a week or so.
Hash cash (no, it's not paying for access through the distribution of drugs). Basically, it is a way of ensuring that the server receiving and acting on a request must spend a certain amount of time computing some function of the input in order to be able to send information back. This normally would not bother a typical user who would only need to respond to requests that match a real file if you set the delay to something like a tenth of a second on a normal computer in use today. The amount of work that needs to be done could be increased to keep up with the growth in speed of computers.
A possible protocol based on hashing:
*Each client selects a random nonce constructed by appending n bits to a representation of the current time in seconds, as well as a header describing how much hash cash would be needed for a valid response.
*Any software receiving the query would be required to construct say x different collisions on the first y-bits of the hash of the nonce, with the input restricted to appending more information to the random nonce.
*If the original client does not a receive a reply containing valid, distinct units of hash cash, the client silently discards the information and places the offending IP on a blocklist. The original client keeps track of the last m units of hash cash to prevent duplicates.
*Each client may set its own threshold for how much hash cash will be needed for a valid reply. Responding clients may choose not to respond if it decides that too much hash cash would be needed.
There are many other alternatives that offer even more control over how much work would be required.
There are certainly stream ciphers that use shift register still in use today. They're wonderfully suited to very fast hardware implementation, have an enormous body of theoretical research supporting them, and take up almost no space at all. Even so, they would not be in violation of the patent.
It's quite simple really; Apple doesn't have and doesn't need to have a valid legal basis to file a lawsuit against the operators of the websites. Their objective is not to win or to recover damages; most such frivolous lawsuits are dismissed. Rather, they seek to stifle public discourse for economic benefit. More generally, this is known as a SLAPP (Strategic Lawsuit Against Public Participation). Normally, SLAPPs are brought by companies against protest groups, individuals, or public interest lobbyists on matters such as environment concerns, real estate developement, and zoning regulations. By transforming what is essentially public debate on issues of wide-ranging concern in a protected public forum into a legal discussion on the *effects* of the debate on the issue, rather than on the issue at hand. Luckily, you can protect yourself by some simple steps:
:-)
-Expressing yourself in a Q-forum (quintessentially public forum) such as a newspaper
-Make sure that your statements of fact are true
-Seek legal advice *before* taking action that may result in a SLAPP
-Move to California or another state with an anti-SLAPP law
Click here for more information
or here
Did you read "Oddly enough, cryptoanalytical and cryptographic secrets are *explicitly exempt* from this automatic declassification system. Moreover, it's probably quite likely that de/reclassification efforts rank rather low among the NSA priorities. It's entirely possible that they simply never got around to it until now."?
BTW, 1933 wasn't in wartime. And the M-134-C represented quite a breakthrough in cryptographic technology at the time. (ObMod) And the moderators are obviously on crack.
You can read the patent for yourself at http://www.patents.ibm.com/details?&pn=US06097812_ _&s_all=1 complete with cross-references. In my opinion, the reason that best explains why the patent has just been issued now is that back in 1933 when Friedman filed for the patent, the information was immediately classified for a set period of time as a matter of course. The FOIA and related executive orders have mandated automatic declassification after 50 years unless it can be demonstrated that disclosure would have a directly detrimental effected on national security. Oddly enough, cryptoanalytical and cryptographic secrets are *explicitly exempt* from this automatic declassification system. Moreover, it's probably quite likely that de/reclassification efforts rank rather low among the NSA priorities. It's entirely possible that they simply never got around to it until now.
- -Jw#LR.
Now for the more speculative reason. The academic/civilian cryptographic research community has never successfully developed a general method for cryptanlysing rotor machines; basically, the limits of what we know how to break is the Enigma with knowledge of the rotor wirings and the SIGABA/ECM systems with knowledge of their rotor wirings. True, there have been vague descriptions of the cryptanalysis of Purple, but the key steps (ie. reconstruction of wirings, and far more importantly, determination of the general structure of the machine without obtaining it) have never been declassified. Rotor machines were very commonplace until about the early sixties; moreover, their descendants, shift register based stream ciphers were probably in use to this day. It's pretty safe to say that there are entire categories of cryptanalytic and cipher design techniques that we are ignorant about.
The sci.crypt newsgroup has a long thread about the patent which can be read, among other places, at http://www.remarq.com/read/cryptsci/q_RGaGOxKZQUC
I want to address the issues in [*], [**], and [+] in a bit of greater detail. The issue of whether RSA is computationally equivalent to the IFP is considerably more up in the air than you imply. The exponents on low exponent RSA and the recent results on the distinguishibility of non-quadratic residues under certain conditions of smoothness for the numbers offset by a small integer from factors of the modulus give me pause on whether the above equivalence is true. It may well be true for the vast majority of RSA moduli. An efficient solution to the DLP *in the case where one operates modulo a composite n*, NOT in GF(p), implies that one can factor composites of the form n. 3DES is the algorithm that I would *trust* the most, but I do not believe that it is the strongest or best designed cipher in common use today; there have been many advances in cryptoanalytic techniques since DES as exemplified by an algorithm like CAST-128.
The algorithms that PGP uses with reasonable length keys are almost certainly not breakable by the NSA in trivial lengths of time (I am not discussing the actual implementation used by any specific version of PGP). The "programmer"'s quote establishes that he or she is obviously incompetent and probably does not work for any defense-related contractor. Jon Katz's use of the quote reveals that he is clueless, but we all suspected that already.
Hash function: PGP in its latest incarnations uses SHA-1, RIPEMD-160, and MD5 in that order of preference. SHA-1 was designed by the NSA and is almost unanamously regarded as the best public hash function today. The expansion function makes it very difficult to control and restrict bit changes within the hash function itself. Even if the NSA were able to create arbitrary collisions on SHA-1, this would not affect the security of the encryption algorithms, only the signature component of PGP. RIPEMD-160 seems reasonably designed; MD5 has serious weaknesses in its compression function. Luckily, almost nobody uses these two hash functions anymore.
Symmetric algorithms: A brute force attack on any encryption algorithm with prudently chosen keylengths (>128 bits) is impossible today and for the forseable future, even with customized hardware. The NSA has cryptanalytic techniques, even decades old, that the academic cryptographic community has not yet discovered. To give some trivial examples, let's look at double transposition, codes, and rotor machines. Even today, the analytic techniques used for the solution of double transposition (without multiple anagramming or known plaintext) were redacted from Friedman's Military Cryptanalytics. The state of linguistic and textual analysis is far more developed in military cryptanalysis circles; centuries of code reconstruction have seen to that. Moreover, the details of attacking advanced rotor machines (essentially anything more sophistocated than the Enigma/Hagelin machines) are still classified. The NSA has shown an ability to design algorithms so fragile that they apparently have precisely the strength they were designed for (visit Skipjack). Nonetheless, if the NSA can break academic algorithms (such as CAST, 3DES, and IDEA), they would be wise to avoid disclosing this fact on something as insignificant as a non-national security related criminal investigation.
Public key algorithms: Without QC, it's impossible that a 1024-bit RSA key will be factored using current algorithms. Even if an extension to GNFS that reduces the hueristic complexity to that of SNFS, 1024-bit RSA keys would require a large enough matrix reduction step that there is probably not enough memory in existence in the world today to do it (even with Balanced Block Lanzcos). It would even be more difficult for the DL problem; the matrix step would require entries to be mod p, rather than mod 2.
I can also think of dual Celerons, dual Pentium 3s, and MP Xeons available today, with the first two at much lower prices than the Apple desktops (with comparable, if not greater performance). So what?
If you won't be reaccessing the data, WTF do you want it polluting even a small part of the the cache hierarchy. The main memory bottleneck will always be present for 1) initial accesses and 2) accesses out of cache. The only solutions are 1) making the cache larger, 2) better algorithms and blocking, or 3) interleaved main memory.
The Itanium has been tapped out; they're working primarily on QC/V and most importantly of all, ramping up clock speed and refining the fab masks. It's an astonishing complex design to verify, but regardless of my opinion of Intel's ISA design teams, their chip designers are among the best in the industry and their verification is equally good (even considering the F00F bug and the floating point SRT errata). Intel will not release a chip as important as the first member of the IA-64 ISA without ensuring that it is functions according to specifications for the especially critical reason that application programers will be using the Itanium to design the first generation of IA-64 compiled applications, applications whose reliability foremost and speed next will be critical to the acceptance of the IA-64 ISA as a force in the HPC market. They simply MUST get it right if they hope to follow their roadmap (Intel and HP have at least half a dozen IA-64 design teams working on the next generation chips) with any credibility. Itanium is basically do or die for Intel; McKinley will come at least half a year and by then the damage to IA-64's reputation may be too much to repair. You can always improve performance, but not if there are no applications for the ISA because no programmer or user wants to deal with processor bugs.
Does absolutely everything have to do with Microsoft? Microsoft does not want to be solely dependent on Intel chips anymore than Intel wants to be tied to Microsoft operating systems.
There are *many* problems with the IA-64 ISA and the specific Itanium implementation of it. I know someone working for HP (the organization that I work for purchases high performance supercomputers on pretty much a regular basis), who reliably states that the SpecFP performance of the Itanium is will be not at all competitive even with today's high end chips *even if it were at the same clock speed*, which it will not. They're barely pushing 700 Mhz even on small scale lots with a hell of a lot more QC than on any production fab.
Intel's moving back of the projected in-volume ship dates for the Itanium is far more important than the release, in limited OEM quantities no less, of an incremental increase in speed grade for the current generation x86 chips. Itanium, as the first line of IA-64 systems, represents the unveiling of a multi-billion dollar gamble by Intel (and its strategic, quasi-partner HP) in making inroads into the high end, 64-bit processor market. IA-64 is an elephantine archetecture; it includes everything including the kitchen sink, the waste disposal, the plumbing, and the hot water heater. It's such an unwieldy ISA for an idea that was supposed to simplify the processor by effectively exposing processor functional units to programmer visible namespace. And yet, Itanium has 10 pipeline stages (3 more than the Alpha 21264, I must add), is barely pushing 500 Mhz, and will probably be slower on a clock for clock basis than the current Alphas and PA-RISCs. I don't buy the ISA, the implementation of the ISA embodied in the Itanium, the projected performance of the Itanium (although I do have greater hopes for HP's Ft. Collins team in the McKinley...it would be hard to see how they could screw up as badly), and the market placement of the initial IA-64 processor line. All in all, I'm not exactly surprised at this delay.
Maybe this means that Intel will have some sense and wait for HP's processor team to finish design so that they can fab the McKinley and avoid embarassment.
C was based on B, which was designed almost entirely by a single person. K&R literally wrote the book on the pre-ANSI C language. C89 codified most of original C. C99 represents only minor changes to the specification of the language (restrict, long longs, and implicit casts to UDTs in actual parameters being the more important changes). C++ was designed by Stroustroup, but unfortunately the committee made some elephantine changes to the language. STL and namespaces is about the only good things, IMHO, that came out of standardization. The latest ISO C++ standard has certain flaws (limits on access of friends, among other things) that I think severely degrade the usefulness of the language.
I have no specific reason to disbelieve that the person you spoke with did in fact used to administer a Cray supercomputer. He may well be correct that certain precautions were neccesary to handle difficulties that arose when components of the machine caught on fire. What I do have problems with were the blatant inaccuracies and panic-mongering in your original comment (production of HF vapor upon ignition of Fluorinert would cause death within thirty seconds). I have no problem with you personally (I just picked this user name as a joke; you can see the comments I've posted in the past to see), just with the content of your post. If I did seem to have a bone to pick with you as a person, I do apologize for that.
You know, that's really a surprise, not using thermos to transport LN since the glass will shatter. I wonder what Dewer bottles are? Oh, that's right, glorified thermos with a reflective coating to prevent heat via radiation transport. Glass will not shatter when cooled to very low temperatures IF you don't do anything stupid with the thermos bottle, such as dropping it on the ground. Not even a liquid-hazmat-transport container will save you from your self (such as leaving one on the trunk of a car, putting said car in reverse, and running over said container). So what do you suggest, in your infinite wisdom, to transport LN? You've eliminated glass and plastic. Presumably, you would suggest transport containers made of metal. [sarcasm]That should solve everything!!![/sarcasm]
Correction: insert a decimal point in 42 mmHg (it should be 4.2 mmHg).
I've addressed your issue about thermal decomposition toxicity in another comment. Fluorinert has a rather low viscosity, but this does not affect its volitility, vapor pressure, or molecular weight (which are what determine the tendency of the vapor to diffuse out of confined spaces). For your information, since you seem to be so concerned, here are the relavent figures (looked up in a MSDS three rooms down):
Boiling point: 215 C
VP: 42 mmHg @ 20 C
Vapor density: 14x air Evaporation rate: 1.7 (Butyl acetate=1)
Viscosity: 14 centistroke @ 20 C
Where do you come up with this crap? When you karam whore, you might as well try to get your facts right instead of fooling moderators into (+1 Informative) with garbage.
It is not enough for the Fluorinert to catch on fire or be next to a fire. What one does have to worry about is thermal decomposition; this will require extreme heat (according to the Material Safety Data Sheets, on the order of 1400 degrees). For comparison, a paper/wood fire burns at most about 700 degrees even with a significant fuel source and a CPU (the "Cray" that you allude to in your garbage anecdote) will not even be able to function with junction temperatures even close to a thousand degrees. You will not achieve thermal decomposition short of heating the Fluorinert on a laboratory burner or sticking molten metal into a beaker of the stuff. You must really misuse and torture the stuff to get anywhere near that point.
Moreover, what you really have to worry about is perfluoroisobutylene instead of hydrogen fluoride vapor. HF's thresehold long term tolerability is about 3ppm and it's LD50 is a lot higher than this. It will take more than 1 breath at any conceivably acheivable concentration to kill you. In any case, even a lethal dose will take more than 30 second to take effect upon intial contact or exposure (I've seen toxicity figures of about 10 minutes for exposure to hydrocyanic acid vapor, significantly more lethal than HF). Perfluoroisobutylene, on the other hand, will inhibit oxygen uptake by selectively binding with the -heme analogues in red blood cells much more efficiently.
Basic summary: Signal 11 is talking out of his ass again. You can mostly ignore his dramatics (but please consult your materials handling and safety staff if you plan to use Fluorinert) if you exercise reasonable prudence and care in using Fluorinert. "EXTREME CAUTION" is not neccesary, in the sense if one were handling certain organic mercury compounds or some other fluorine/chlorine compounds. Oh, and the oxygen masks: they're there so that any person unfortunate to be stuck in the machine room and who cannot reach the hold-off switch will not sufficate from oxygen displacement, not for poisoning (which would require a directed positive pressure system, instead of a mere supplementary oxygen mask).
You are correct; I had forgoten about implied type specifiers. For the purists out there, the last publicly available draft can be read at http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n84 3.htm. Its dated August 3, 1998, but there are no major differences between this draft and the final C99 standard. It is on pages 107-108 of the draft and pages 114-116 of the final standard.
The "spliting the 64-bit core into two x86 32-bit cores" idea could not possibly work efficiently. It is quite safe to say that the AMD folks must have come to their senses by now and abandoned any thought of doing Sledgehammer that way. A modern chip trace (say an adder) is highly optimized for the word size and rely critically on signal propagation delay for the most efficiency. Spliting (using the previous example of an adder) into 2 32-bit adders would result in totally incorrect results or a nonoptimal implementation, at which point one is better off just designing the functional units seperately.
x86 *is* a terrible ISA and backwards compatibility *does* hold back tech, both in terms of performance and price/performance. If we were not shackled with the x86 ISA so pervasively, the design and fabrication talent that Intel and AMD so obviously possess could have been far better used to design chips whose performance would have been incredible. My reasoning is that if one is willing to go so such lengths and create a new ISA (albeit one that is supposedly compatible with x86 and that extends it), thereby requirely new compilers and OS support, one should go all the way and just start from scratch and use a decent, sane, reasonable ISA.
I already do use Alphas. What really bothers me is that the fab techniques and capacity (not to mention the design teams) could be far more productively used to create chips based on a reasonable ISA. An Alpha, with the design funding of an Intel or AMD, combined with their wonderful fabs would be awe-inspiring and would bring true supercomputing level performance (at a much more reasonable price, comparable to current x86 chip prices) to the desktop, in addition to being much more pleasant to code for.