Data compression IS impossible in the most general case, as paradoxical as that may seem. The best we can do are some heuristic algorithms that happen to reduce in size most of the inputs that such algorithms encounter in day to day usage. Lossless compression will and always must be limited by information theory; you cannot get more information out of a given output to a compression algorithm than can be represented by the set of all states of the output: a n-bit output to ANY reversible compression algorithm can have no more than 2^n preimages that when compressed produced such an output. This is not an empirical observation based on a specific compression algorithm now in use, but a theoretical one based on simple information entropy considerations.
A lossless reversible compression algorithm that signficantly (indeed at all) reduces in length more than a minute proportion of all possible inputs (please contact me if you want a clarification of this statement; I'm handwaving the precise definition of the phrase minute proportion) is impossible. It will simply not happen. The pigeonhole principle is the most basic argument against universal compressors; a given string of bits cannot represent more *distinct* other string of bits than the total number of *distinct* states of that string of bits.
Your "big breakthrough" is a standard claim made by a) well-meaning people who think they have a great new algorithm that revolutionizes data compression or b) con-artists who want to persuade people to part with their money for the next best thing. The key difference is that the first category is usually willing to learn.
For more information, please read the comp.compression FAQ.
The answer to your question is no. Very briefly, it is not possible to build a universal compressor that can reduce the size of all possible inputs, nor is it possible for a compressor to emit an output with less information content (ie. Shannon entropy) than the input. It is not possible to have a compressor that takes in, say all 1MB text files, and always outputs 10k compressed files simply because most 1MB text files contain more information than can be expressed in 10k.
A much more intuitive argument is the "pigeonhole principle." Let's assume that there are 16 holes in a wall, to which each is associated with a message. It is impossible for 17 messages to each be uniquely associated with a hole because there are not enough holes avalible. A 4-bit file can only represent 16 different messages, regardless of what algorithm is used to compress the message...unless, that is, you don't care about the compression being reversible!
z = (z = g - w) > (unsigned)l ? l : z; I hate to sound like I'm flaming you, but this is the standard idiom in C for addition with saturation. When (g-w) is larger than a certain constant l, z is assigned to that constant l, otherwise, z will retain its value. This code can also be written less efficiently (well, at least if your compiler doesn't have common sub-expression elimination) as: if((g-w) > (unsigned) l){ z=l; } else { z=g-w; }
MuPAD: nice general purpose CAS with packages for practically anything. You can view the source for the library functions, so if there's bug, you can fix it. Support is excellent and it's essentially free (as in beer) for *nix systems; MuPAD Light is free for Windows systems. www.sciface.com
PariGP: Has a decent user interface but not especially user-friendly compared to MuPAD's programming language. Has excellent support for formal power series, rings, etc.
Macaulay: User interface is bare bones; just flushes input to the interpreter. Strong in manipulation of polynomials via Grobner basis. It seems specialized for computational algebraic geometry.
Ouch, that's embarassing. My thesis advisor would probably have had me drawn and quartered for that. I misstated Richardson's theorem: R is the class of expressions formed by: 1) The rationals, PI, and ln(2) 2)A single dependent variable x 3) The operations of addition and multiplication, and 4) The sine, cosine, exponential, and absolute value functions. Composition is allowed, of course. The predicate E=0 cannot be decided for arbitrary E in R.
I think the above paragraph is right, but I'm not sure I got all the details right and those little proof demons always lurk in the details...
Your statement is not strictly true. In order to define equality of two functions, we must establish the mathematical space under which the functional operations are carried out. In the case of the reals, the space has enough underlying structure (ie. Taylor series, Cauchy-Dedekind representations) that we can prove equality for a certain small minority of functions defined over the reals. This is not as trivial as it seems; a theorem by Richardson states that [handwaving here; read the proof for the details] even for a surprisingly simple class of expressions over R (the rational numbers), the predicative identity E=0, where E is a any finite, recursively definable expression under the certain strict constraints, is not decidable. Your posting is not generally correct, but nonetheless applicable for the question of the RSA function, unless there is something very surprising that we have yet to discover about it.
RSA is not something like a sorting algorithm or a FFT; the Perl slogan There's More Than One Way to Do It is not applicable here. If we model the core RSA function m=c^e mod n as an bijective function f() from Z/Z_n -> Z/Z_n (the field defined by the integers modulo), simple uniqueness considerations on the operators over the field dictate that there is no other function g() that maps the same bijection between Z/Z_n -> Z/Z_n that is distinct from f(). Neccesarily, if f(x)=g(x) for all inputs {x|x E Z/Z_n}, the function f()==g() for a sufficiently broad generalization of the underlying field (irrespective of the specific structure of the field). Essentially, any shortcut that allows the computation of the RSA function without carrying out the same operation means that the RSA function has an some extremely unexpected properties. RSA is probably broken if it ever gets to that point.
Utter nonsense, Signal 11. The inertial vector of the system (and by extension the angular momentum vector and any associated torque effects that airflow may cause) is directed outward normal to the plane of the CD, just like any other CD. Please try to learn something about a topic before posting.
16-bit composites can be decomposed into prime factors in much, much, much less than a second. Assuming that the worst case scenario of two 8-bit prime factors holds, a naive brute force test all primes up to sqrt() factoring algorithm takes about 8000 cycles to factor the number (checked using the pentium RTDSC instruction).
This is an extradinarily insightful comment. This Quake mod author, in all probability, does not have anywhere the legal resources of a MPAA or Microsoft. No legal precedent has ever been set about the GPL in any court of law; it would be far wiser to establish one against someone unable to corrupt the judicial process to the extent that are able to do through their massive warchests. Who cares if we don't get the Quake modification's source code for a couple of years if we can obtain a reasonably firm assertion of the validity of the GPL?
No, it doesn't. 1) void foo( Bar bar ); 2) void foo( const Bar& bar );
foo in 1 and foo in 2 cannot be overloaded because their formal parameters types are identical. This is not a problem; no compiler can reasonably disambiguate the function calls at compile time or even run time for that matter. What I'm thinking of is that there is no way to tell whether an arbitrary function call (ie. foo(x)) is passing a value or passing by reference by examining the context of the point at which the call is made.
Nope, just examine the output for any nontrivial bit of code that really uses floating point. Intel's VTune compiler and even Microsoft's VC++ compiler usually achieve more than 20% improvements on floating point intensive code. The GCC x86 code generator does not know how to utilize the x87 FP stack effectively, especialy the FXCH instruction which is practically free on modern Intel chips.
The most impressive compilers that I've ever seen would have to be either the Alpha or the SGI Fortran compiler. Interprocedural optimizations, code profiling, basic blow movement, full alias analysis, etc. *Very* good.
I'm sorry, but you obviously haven't compared the quality of the code generated by gcc with that generated by any Borland, Microsoft, or Intel's C compiler. Frankly, the commercial compilers blow gcc out of the water, even with pgcc -O6 -march=pentiumpro -fomit-frame-pointer -etc. gcc is *extremely* impressive for what it does, as it is portable to a zillion different OSes and CPUs, but this very portability makes it less than optimal at generating code for any one CPU. The internal RTL representation does not lend itself to the detailed modelling of the Intel x86 crappy archetecture so critical to acheiving good performance, especially with a stack-based FPU.
Err, the figures that I referred to were in Celsius. I think that you misunderstand what T_j is. T_j is not the temperature of the surface of the chip, but rather the junction between adjacent non-similarly doped areas of silicon. T_j in a normal desktop or laptop computer is significantly higher than room temperature; I don't have any exact figures handy, but I would be willing to bet that T_j is over a hundred degrees C in any commericial x86 chip operating under normal conditions.
On a related note that makes me suspect the conditions under which this result was obtained, at a recent Intel Developer Forum demonstration, Intel unveiled a P3 (ie. Coppermine) operating at 1Ghz. An audience member asked what temperature the result was done at. Intel replied room temperature. Another audience member asked what room temperature was. Intel replied the 20 degrees. Yet another audience members asked which part of the chip was measured at 20 degrees. Intel replies T_j (the temperature at the junction)!!!
For those not conversant in chip design, this means that the "room temperature" must have been near Antarctic for T_j to be 20 degrees. Gotta love Intel.
What is this garbage? This makes absolutely no sense at all; please present your algorithm in a coherent fashion using standard mathematical notation or at the very least, some decent pseudocode. "Decreasion number," "looping factor", "6 neighbor," and "numerical method which is designed to reduce certain difference" have no meaning whatsoever. Your method seems to be a variation of Fermat's factoring method which starts from sqrt(n) and sieves downward based on congruences; this is dreadfully inefficient compared to modern factoring methods. The time complexity of Fermat's method is fully exponential and the O(0) factor is quite high for classical techniques; it is not even competitive with the Pollard/Brent rho method or the Pollard p+/-1 method.
Drnomad appears to be a crank; it's not worth any more of my time to wade through the stuff he pours out.
They can use the d.net approach: open-source the compute portion and then link it with the closed-source binary only networking code. Put in some redundancy to make sure clients are doing all the checks; for example, ask for various intermediate values calcuated during the FFTs. The math done by the program is NOT advanced: any undergraduate compsci student should have enough math background to understand it. The implementation of the FFT in SETI@home looks to be rather poorly done, but of course one can't tell for sure because I don't have a copy of the source. Nonetheless, other public available FFT implementations (in generic C/Fortran code, not to mention machine optimized vendor or scientific computing libraries) tend to perform significantly better on equivalent sized transform block, such as FFTW, and Dan Bernstein's FFT library. The people running SETI@home are top-notch, so I don't think their poor coding is accidental...they simply see no need for clients to process data faster.
It is quite obvious that you have little experience designing or implementing programable logic devices. 1Mb/sec is a *very* low target speed to shoot for if you're going to go to the bother of making a hardware encryption acceleration device. Blowfish is not especially well suited for hardware implementation; you need a 4K ROM to store the digits of pi and (this is the big one) 4K of RAM to store the key-dependent S-box. There are other ciphers that would be better uses of key space. Nonetheless, any decent implementation of a modern block cipher should be able to acheive at least 10 Mb/sec without pipelining or unreasonable use of chip space. With pipelining and appropiate interleaved encryption modes, (16x duplication of logic) I would think that 100 Mb/sec would not be an unreasonable goal, if not even significantly faster.
Implementing RSA in hardware requires more finesse in that timing the carry-save delays and allocating space for multipliers becomes slightly trickier. The key operation is multi-precision modular exponentiation which can be done with general purpose hardware quite well. It doesn't make much sense to put in into a board devoted to symmetric algorithms.
Well yes. A skilled cryptanalyst can break a monoalphabetic substitution cipher in about 30 letters, much less if he/she can do crib dragging. Nonetheless, there are no publicly known practical attacks on modern, widely used cryptographic algorithms that use reasonable amounts of text. Even the best non-brute force DES attack needs 2^4? work and about the same number of *chosen* text. Shannon entropy theory dictates that any block cipher can be broken if he amount of information available to the analyst is larger than the unicity distance of the plaintext; that doesn't mean the only practically secure system is the OTP.
I don't think this really needs saying, as anyone who as been keeping tabs on world news should know this already, but the Mexican government has practically lost legitmacy in terms of being able to exert real control over areas of the country far from the centralized administration in Mexico City. The economy has not grown for the past several years and the unemployment rate *in the city* is upwards of 30% even by the generous official calculations. It is estimated that by any reasonable standard of poverty/living wage allotments, less 40% of people are functionally employed. Literacy among youth, especially rural youth, is at astonishingly low levels. Honestly, I don't think they're in much of a position to roll out ~140,000 computers or worry about which distro/window manager to use.
Come on. QC will not be practical for at least a couple of decades; quantum decoherence and other interference effects will be very difficult to surmount as the number of qubits increases (search xxx.lanl.gov for the precise references). Normal computers, regardless of how small the process technology and architectural design, will never be able to brute force a 128-bit key. Period.
Shamir's device is an advanced photoelectronic computer that performs the sieving phase of the NFS or MPQS factoring algorithms several orders of magnitude more cost-effective. However, the major obstacle is not the sieving phase, which is easily distributed, but rather the matrix reduction phase which must be done on a machine with immense ammounts of memory and low latency. Even with SGE and block Lancos methods, it's inconceivable that enough memory will ever be built to accomodate reducing the matrix from a 768-bit RSA key. The situation is even worse for discrete log systems by a couple orders of magnitude.
There is no such thing as being too restrictive by denying by default. I know exactly what daemons should be running on the machines behind the firewall and as such, I know exactly which ports which processes should have access to. Any outside user should not be randomly trying to access ports, regardless of their number. Even script kiddies can figure out how to change the default port: end of story. Any other security approach requires far more proactivity to acheive a lesser level of protection.
They do need to be configured correctly, and block out common "trojan-ports" (12345 (netbus), 31337 (bo), and so forth). This to ensure that no sloppy employee gets his computer backdoored -- and the rest of the net gets access to it.
No! Security by filtering out dangerous ports does not work. Rather, one should filter unknown ports by default and specifically let "safe" ports through the firewall. Look at Hotmail/other webmail providers' problems with embedded javascript in email that are supposed to be escaped out or removed.
Slashdot Mirror
Data compression IS impossible in the most general case, as paradoxical as that may seem. The best we can do are some heuristic algorithms that happen to reduce in size most of the inputs that such algorithms encounter in day to day usage. Lossless compression will and always must be limited by information theory; you cannot get more information out of a given output to a compression algorithm than can be represented by the set of all states of the output: a n-bit output to ANY reversible compression algorithm can have no more than 2^n preimages that when compressed produced such an output. This is not an empirical observation based on a specific compression algorithm now in use, but a theoretical one based on simple information entropy considerations.
A lossless reversible compression algorithm that signficantly (indeed at all) reduces in length more than a minute proportion of all possible inputs (please contact me if you want a clarification of this statement; I'm handwaving the precise definition of the phrase minute proportion) is impossible. It will simply not happen. The pigeonhole principle is the most basic argument against universal compressors; a given string of bits cannot represent more *distinct* other string of bits than the total number of *distinct* states of that string of bits.
Your "big breakthrough" is a standard claim made by a) well-meaning people who think they have a great new algorithm that revolutionizes data compression or b) con-artists who want to persuade people to part with their money for the next best thing. The key difference is that the first category is usually willing to learn.
For more information, please read the comp.compression FAQ.
The answer to your question is no. Very briefly, it is not possible to build a universal compressor that can reduce the size of all possible inputs, nor is it possible for a compressor to emit an output with less information content (ie. Shannon entropy) than the input. It is not possible to have a compressor that takes in, say all 1MB text files, and always outputs 10k compressed files simply because most 1MB text files contain more information than can be expressed in 10k.
A much more intuitive argument is the "pigeonhole principle." Let's assume that there are 16 holes in a wall, to which each is associated with a message. It is impossible for 17 messages to each be uniquely associated with a hole because there are not enough holes avalible. A 4-bit file can only represent 16 different messages, regardless of what algorithm is used to compress the message...unless, that is, you don't care about the compression being reversible!
z = (z = g - w) > (unsigned)l ? l : z;
I hate to sound like I'm flaming you, but this is the standard idiom in C for addition with saturation. When (g-w) is larger than a certain constant l, z is assigned to that constant l, otherwise, z will retain its value.
This code can also be written less efficiently (well, at least if your compiler doesn't have common sub-expression elimination) as:
if((g-w) > (unsigned) l){
z=l;
} else {
z=g-w;
}
MuPAD: nice general purpose CAS with packages for practically anything. You can view the source for the library functions, so if there's bug, you can fix it. Support is excellent and it's essentially free (as in beer) for *nix systems; MuPAD Light is free for Windows systems. www.sciface.com
PariGP: Has a decent user interface but not especially user-friendly compared to MuPAD's programming language. Has excellent support for formal power series, rings, etc.
Macaulay: User interface is bare bones; just flushes input to the interpreter. Strong in manipulation of polynomials via Grobner basis. It seems specialized for computational algebraic geometry.
Ouch, that's embarassing. My thesis advisor would probably have had me drawn and quartered for that. I misstated Richardson's theorem: R is the class of expressions formed by: 1) The rationals, PI, and ln(2) 2)A single dependent variable x 3) The operations of addition and multiplication, and 4) The sine, cosine, exponential, and absolute value functions. Composition is allowed, of course. The predicate E=0 cannot be decided for arbitrary E in R.
I think the above paragraph is right, but I'm not sure I got all the details right and those little proof demons always lurk in the details...
Your statement is not strictly true. In order to define equality of two functions, we must establish the mathematical space under which the functional operations are carried out. In the case of the reals, the space has enough underlying structure (ie. Taylor series, Cauchy-Dedekind representations) that we can prove equality for a certain small minority of functions defined over the reals. This is not as trivial as it seems; a theorem by Richardson states that [handwaving here; read the proof for the details] even for a surprisingly simple class of expressions over R (the rational numbers), the predicative identity E=0, where E is a any finite, recursively definable expression under the certain strict constraints, is not decidable. Your posting is not generally correct, but nonetheless applicable for the question of the RSA function, unless there is something very surprising that we have yet to discover about it.
RSA is not something like a sorting algorithm or a FFT; the Perl slogan There's More Than One Way to Do It is not applicable here. If we model the core RSA function m=c^e mod n as an bijective function f() from Z/Z_n -> Z/Z_n (the field defined by the integers modulo), simple uniqueness considerations on the operators over the field dictate that there is no other function g() that maps the same bijection between Z/Z_n -> Z/Z_n that is distinct from f(). Neccesarily, if f(x)=g(x) for all inputs {x|x E Z/Z_n}, the function f()==g() for a sufficiently broad generalization of the underlying field (irrespective of the specific structure of the field). Essentially, any shortcut that allows the computation of the RSA function without carrying out the same operation means that the RSA function has an some extremely unexpected properties. RSA is probably broken if it ever gets to that point.
Utter nonsense, Signal 11. The inertial vector of the system (and by extension the angular momentum vector and any associated torque effects that airflow may cause) is directed outward normal to the plane of the CD, just like any other CD. Please try to learn something about a topic before posting.
16-bit composites can be decomposed into prime factors in much, much, much less than a second. Assuming that the worst case scenario of two 8-bit prime factors holds, a naive brute force test all primes up to sqrt() factoring algorithm takes about 8000 cycles to factor the number (checked using the pentium RTDSC instruction).
This is an extradinarily insightful comment. This Quake mod author, in all probability, does not have anywhere the legal resources of a MPAA or Microsoft. No legal precedent has ever been set about the GPL in any court of law; it would be far wiser to establish one against someone unable to corrupt the judicial process to the extent that are able to do through their massive warchests. Who cares if we don't get the Quake modification's source code for a couple of years if we can obtain a reasonably firm assertion of the validity of the GPL?
No, it doesn't.
1) void foo( Bar bar );
2) void foo( const Bar& bar );
foo in 1 and foo in 2 cannot be overloaded because their formal parameters types are identical. This is not a problem; no compiler can reasonably disambiguate the function calls at compile time or even run time for that matter. What I'm thinking of is that there is no way to tell whether an arbitrary function call (ie. foo(x)) is passing a value or passing by reference by examining the context of the point at which the call is made.
Why was the decision made not have have references visible as parameters in the calling context of a function call?
Nope, just examine the output for any nontrivial bit of code that really uses floating point. Intel's VTune compiler and even Microsoft's VC++ compiler usually achieve more than 20% improvements on floating point intensive code. The GCC x86 code generator does not know how to utilize the x87 FP stack effectively, especialy the FXCH instruction which is practically free on modern Intel chips.
The most impressive compilers that I've ever seen would have to be either the Alpha or the SGI Fortran compiler. Interprocedural optimizations, code profiling, basic blow movement, full alias analysis, etc. *Very* good.
I'm sorry, but you obviously haven't compared the quality of the code generated by gcc with that generated by any Borland, Microsoft, or Intel's C compiler. Frankly, the commercial compilers blow gcc out of the water, even with pgcc -O6 -march=pentiumpro -fomit-frame-pointer -etc. gcc is *extremely* impressive for what it does, as it is portable to a zillion different OSes and CPUs, but this very portability makes it less than optimal at generating code for any one CPU. The internal RTL representation does not lend itself to the detailed modelling of the Intel x86 crappy archetecture so critical to acheiving good performance, especially with a stack-based FPU.
MACHO=Massive compact halo objects
Err, the figures that I referred to were in Celsius. I think that you misunderstand what T_j is. T_j is not the temperature of the surface of the chip, but rather the junction between adjacent non-similarly doped areas of silicon. T_j in a normal desktop or laptop computer is significantly higher than room temperature; I don't have any exact figures handy, but I would be willing to bet that T_j is over a hundred degrees C in any commericial x86 chip operating under normal conditions.
On a related note that makes me suspect the conditions under which this result was obtained, at a recent Intel Developer Forum demonstration, Intel unveiled a P3 (ie. Coppermine) operating at 1Ghz. An audience member asked what temperature the result was done at. Intel replied room temperature. Another audience member asked what room temperature was. Intel replied the 20 degrees. Yet another audience members asked which part of the chip was measured at 20 degrees. Intel replies T_j (the temperature at the junction)!!!
For those not conversant in chip design, this means that the "room temperature" must have been near Antarctic for T_j to be 20 degrees. Gotta love Intel.
What is this garbage? This makes absolutely no sense at all; please present your algorithm in a coherent fashion using standard mathematical notation or at the very least, some decent pseudocode. "Decreasion number," "looping factor", "6 neighbor," and "numerical method which is designed to reduce certain difference" have no meaning whatsoever. Your method seems to be a variation of Fermat's factoring method which starts from sqrt(n) and sieves downward based on congruences; this is dreadfully inefficient compared to modern factoring methods. The time complexity of Fermat's method is fully exponential and the O(0) factor is quite high for classical techniques; it is not even competitive with the Pollard/Brent rho method or the Pollard p+/-1 method.
Drnomad appears to be a crank; it's not worth any more of my time to wade through the stuff he pours out.
They can use the d.net approach: open-source the compute portion and then link it with the closed-source binary only networking code. Put in some redundancy to make sure clients are doing all the checks; for example, ask for various intermediate values calcuated during the FFTs. The math done by the program is NOT advanced: any undergraduate compsci student should have enough math background to understand it. The implementation of the FFT in SETI@home looks to be rather poorly done, but of course one can't tell for sure because I don't have a copy of the source. Nonetheless, other public available FFT implementations (in generic C/Fortran code, not to mention machine optimized vendor or scientific computing libraries) tend to perform significantly better on equivalent sized transform block, such as FFTW, and Dan Bernstein's FFT library. The people running SETI@home are top-notch, so I don't think their poor coding is accidental...they simply see no need for clients to process data faster.
It is quite obvious that you have little experience designing or implementing programable logic devices. 1Mb/sec is a *very* low target speed to shoot for if you're going to go to the bother of making a hardware encryption acceleration device. Blowfish is not especially well suited for hardware implementation; you need a 4K ROM to store the digits of pi and (this is the big one) 4K of RAM to store the key-dependent S-box. There are other ciphers that would be better uses of key space. Nonetheless, any decent implementation of a modern block cipher should be able to acheive at least 10 Mb/sec without pipelining or unreasonable use of chip space. With pipelining and appropiate interleaved encryption modes, (16x duplication of logic) I would think that 100 Mb/sec would not be an unreasonable goal, if not even significantly faster.
Implementing RSA in hardware requires more finesse in that timing the carry-save delays and allocating space for multipliers becomes slightly trickier. The key operation is multi-precision modular exponentiation which can be done with general purpose hardware quite well. It doesn't make much sense to put in into a board devoted to symmetric algorithms.
Well yes. A skilled cryptanalyst can break a monoalphabetic substitution cipher in about 30 letters, much less if he/she can do crib dragging. Nonetheless, there are no publicly known practical attacks on modern, widely used cryptographic algorithms that use reasonable amounts of text. Even the best non-brute force DES attack needs 2^4? work and about the same number of *chosen* text. Shannon entropy theory dictates that any block cipher can be broken if he amount of information available to the analyst is larger than the unicity distance of the plaintext; that doesn't mean the only practically secure system is the OTP.
I don't think this really needs saying, as anyone who as been keeping tabs on world news should know this already, but the Mexican government has practically lost legitmacy in terms of being able to exert real control over areas of the country far from the centralized administration in Mexico City. The economy has not grown for the past several years and the unemployment rate *in the city* is upwards of 30% even by the generous official calculations. It is estimated that by any reasonable standard of poverty/living wage allotments, less 40% of people are functionally employed. Literacy among youth, especially rural youth, is at astonishingly low levels. Honestly, I don't think they're in much of a position to roll out ~140,000 computers or worry about which distro/window manager to use.
Come on. QC will not be practical for at least a couple of decades; quantum decoherence and other interference effects will be very difficult to surmount as the number of qubits increases (search xxx.lanl.gov for the precise references). Normal computers, regardless of how small the process technology and architectural design, will never be able to brute force a 128-bit key. Period.
Shamir's device is an advanced photoelectronic computer that performs the sieving phase of the NFS or MPQS factoring algorithms several orders of magnitude more cost-effective. However, the major obstacle is not the sieving phase, which is easily distributed, but rather the matrix reduction phase which must be done on a machine with immense ammounts of memory and low latency. Even with SGE and block Lancos methods, it's inconceivable that enough memory will ever be built to accomodate reducing the matrix from a 768-bit RSA key. The situation is even worse for discrete log systems by a couple orders of magnitude.
There is no such thing as being too restrictive by denying by default. I know exactly what daemons should be running on the machines behind the firewall and as such, I know exactly which ports which processes should have access to. Any outside user should not be randomly trying to access ports, regardless of their number. Even script kiddies can figure out how to change the default port: end of story. Any other security approach requires far more proactivity to acheive a lesser level of protection.
They do need to be configured correctly, and block out common "trojan-ports" (12345 (netbus), 31337 (bo), and so forth). This to ensure that no sloppy employee gets his computer backdoored -- and the rest of the net gets access to it.
No! Security by filtering out dangerous ports does not work. Rather, one should filter unknown ports by default and specifically let "safe" ports through the firewall. Look at Hotmail/other webmail providers' problems with embedded javascript in email that are supposed to be escaped out or removed.