I have _The Story of Magic_ and the information is not nearly enough to implement a realistic attack on PURPLE. An appropiate analogy would be Feynman's "Six Easy Pieces" versus something like "The Large Scale Structure of Space-Time" by Ellis, Hawking or Misner, Thorne, Wheeler's "Gravitation." You would be able to handwave a description of gtr with the first one, but you wouldn't be able to anything quantitative. Likewise, _The Story of Magic_ leaves out the all-critical details about the reconstruction of the V->V and C->C tables.
The Enigma was only used for short-term tactical communications. The Army and Air Force version used 3 wheels, while the later naval versions used 4 wheels. All of the Enigma cryptosystems shared certain traits that made them especially amenable to a type of cryptanalysis known as the Index of Coincidence method (a letter could never be encrypted to its plaintext equivalent). There was never any real need to capture a naval Enigma, although if this occured, it would certainly have been a great help. Later German innovations, such as the plugboard and better keying techniques, made it more difficult for British cryptanalysts to break Enigma messages in useful durations of time. While there are indeed more than 3 extant Enigma machines, I believe that the article refers to 3 of a specific type and manufacture.
The details of the high-level encryption systems (such as the Lorentz cipher machines between German operational command and the leadership) have not ever been declassified yet, although it is known that they too were broken by the Allies. To this day, the details of how the Japanese PURPLE machine was broken are not known either. Rotor machines were used by the Allies as well during WWII, and by most nations until probably the late 1950s. It has additionally been rumored that codebreaking agencies had discovered astonishingly general techniques for breaking messages encrypted with rotor machines.
Compilers are certainly important, but I think even more important is the algorithm. It goes well beyond simple big-O complexity notation. To take the example of inverting a matrix, even though most classic algorithms are O(n^3), you have to take into consideration the cache characteristics of the algorithm used, the sparsity of the matrix, and other factors such as the specific form of the matrix and possible numerical instability. If your algorithm involves trig functions, or for that matter, division, in its innermost loop, you've probably got a big problem. I don't know of *any* processor with a division operation latency of under 8 clocks. It's probably time to reshuffle your implementation or pick a more suitable algorithm.
BTW, O(a^n) in standard notation is ill-defined, but would probably be interpreted as an exponential growth function with some arbitrary, but fixed, constant a. That places the problem squarely in the category of intractable. Although there are some very clever algorithms that can help in some cases (lattice basis reduction comes to mind).
"Here's a contrast to hopefully clarify it a bit: writing a program in machine code is typically 50x faster than letting a compiler generate it."
Bullshit. On most applications, good compiler generated code is not usually more than 60-70% slower than hand-tuned assembly. I've seen some exceptions to this general rule (ie. naive dot product vs. scheduled dot product on the x87 FPU stack), but the worst I've ever seen was about 8-10 times slower. Show me an application which gets a "50x" performance increase from writing the assembly yourself. Hell, just show me a code fragment from the kernel of the function, and I'll either show you why the code is either miserably written or I'll submit a patch to GCC to optimize for that case. That's a promise and you can hold me to it.
developer.intel.com has many good instruction reference guides in PDF format. I don't have any exact links, but try searching under "StrongARM Instruction Reference." I'm quite an advocate of the *ARM family; it's one of the few ISAs that is orthogonal enough that everything makes sense, and yet complete enough that you don't have to resort to crazy idiomic code fragments to get something useful done. If only Intel would give up their Pentium II's and use some of that great process technology on the StrongARMs:-).
What exact question is it that you are asking? The answer depends to a great extent upon the specifics of your problem. For some possible usage scenarios, here are my suggestions (disclaimer: I have a preference for SGI machines, because those are what I primarily use from day to day)
Standard office applications:Go for a cheap Celeron and lots of RAM. Most applications will be very responsive in any case. 3D games: an Athlon would probably be your best choice. Decent FPU performance, good integer performance, won't cost you a bundle. Most games don't really benefit from SMP anyway. Render farms, other highly parallel, low internode communction applications: commodity x86 systems, the more the better. RT control of other systems/experimental setups: I personally prefer the StrongARM series of processors for this role, since the price/performance is practically unmatched, the documentation is through, and programming in assembly for the SA is truly a joy compared to the hideous mess that is the x86. Only problem is that there no FPU (it does have an integer multiply though). Data mining, data warehousing: I don't have any personal experience with these applications, but I have heard good things about Suns and the RS/6000's from IBM. Single-threaded or low parallelism scientific computations: Definitely Alphas. They blow any other processor away on floating point intensive operations. The only real drawback is lack of CCNUMA/massively parallel shared-memory systems. IIRC, they top off at 8 or 16 processors. Really big simultions, computational hydrodynamics, etc.: Keeping in mind my previous disclaimer, I would still have to suggest SGI Origin 2000 systems for this type of task. The out-of-box performance on a fully populated Origin 2000 is awe-inspiring. Another option might possibly be linked AS/400s or RS/6000s or even one of the Cray T3Es for vector oriented codes. A bit pricy, but if it's not your money...
Re:An interesting loophole...
on
BeOS For Linux!
·
· Score: 2
This is utterly untrue. I can't even begin to imagine where you got this misinformation from. Did you just make it up because it sounded good? The absence of a license agreement does not indicate that the entity that holds the rights to the software has a)given up his or her rights to such software or b)that the user is not legally able to use the software. Precedent would suggest that the copyright holder retains the right to the software, although the entity would be unable to coerce a user of the software to abide by any retroactive license agreement. The user would be unable to use Be's intellectual property as his or her own, but would not be required to abide by, say a future clause against reverse engineering or decompilation of code.
I *think* this is a joke, since the article references "US Patent No. 45,487,338,209, 'A system for organizing user-submitted text by means of collaborative ranking' and US Patent No. 46,773,228,287." I am certain that the number of patents issues is below well below 46 billion. Another link in the article points to http://63.196.208.222/frameset.html (nominally PR Newswire, but check out the reverse DNS and dig on that IP) wherein it states that "According to intellectual property expert Rob Enderly of the Giga Information Group, the patent most likely to be asserted is 5,876,324." Apart from the rather fake sounding name, the disreprency in patent numbers makes me suspicious, as does the actual content of that patent (hint). Finally, at the bottom of that page, you have the story "Red Hat, VA Linux Systems in bidding war for "Harry Potter" series," an obviously fake April Fools Story. In conclusion, it seems to be a well-planned and well-executed joke. I commend them.
A reasonably accurate description of vector operations (or more accurately Single Instruction, Multiple Data operations), but is it truly necessary to bring in the linear algebra concept of a vector space? Strictly speaking, your defintion is not even entirely correct or complete. You define b and c as doubles, while b and c are formally scalar quantities; it is entirely acceptable for b and c to be defined over the scalar field of the complex numbers. Moreover, it is not entirely true that all vector spaces can be represented as an ordered list of numbers. For certain vector spaces, some structure (ie. existence of a inner product) is lost when the representation of the vector space is coerced into such a form. You also fail to present the closure properties of formal vector spaces with regard to scalar multiplication and addition as defined over the vector space. In the future, please karma whore in a more accurate fashion.
That's generally true, baring details about semantics and Karp reductions, but nobody has ever shown that factoring or the RSA problem is in NP-Complete! If somebody could demonstrate this, it would be quite a breakthrough in our understanding of the computational complexity of this problem and others related to the RSAP, like the DLP.
Knapsack PKC=based on knowing which subset of values in a given set will sum exactly to a certain fixed value (the size of the knapsack)
L^3 algorithm=Lenstra-Lenstra-Lovasz Lattice reduction algorithm; guaranteed to find a basis for a lattice with elements of length not more than a certain [theoretically exponential, but in practice only superpolynomial] length longer than the shortest basis for such a lattice. Used for reducing the lattice formed when inverting many knapsack PKC into a more easily handled size.
The following is a short summary of the effect that quantum computing will have on cryptography by type of cryptographic primitive, as is currently accepted by a consensus of cryptographers: public key cryptosystems based on factoring or extracting discrete logs over a prime field- practical quantum computing will make these systems essentially useless, since the sender of the messages will have no inherent computational advantage over the attacker
public key cryptosystems based on discrete logs over eliptic curve- not much research has been done in this area, but it is not immediately apparent that quantum computing will nesessarily create a trivial break of this problem
public key cryptosystems based on knapsack problem- pretty much obselete already thanks to the L^3 lattice reduction algorithm; not much to worry about
public key cryptosystems based on calculations in a truncated polynomial ring modulo different small primes (ie. NTRU)- probably not much to worry about, as there is no apparent reduction from factoring to converting between different ring representations of a polynomial (the main attack is via the L^3 algorithm)
symmetric algorithms- square root reduction in brute force time
hash functions- theoretical square root reduction in time to find collisions; it isn't clear how to achieve this, though
general NP problems - surprisingly, recent results show that quantum computers may not be able to solve general problems in the space NP-Hard. Search on xxx.lanl.gov for a preprints about the (surprising relative lackof) Hamiltonian nonlinearity properties in quantum wave functions.
Actually, QC will make factoring large composites much easier than by a mere square root. Decomposition of large composites into primes can be done in NP-time; a QC will enable us to factor these composites in strictly polynomial time, whereas the best current factoring algorithms (NFS for general numbers, ECM for many medium sized factors) take subexponential time. The square root reduction applies to *conventional* symmetric encryption algorithms in the case of a brute force attack.
Excuse me? "Darn barrell shifters are so expensive in hardware"? Have you ever even seen a hardware VLSI design tool? Have you even heard of Verilog? In terms of hardware cost, a barrel shifter takes much less space than a fast carry-save or carry-branch adder. Flinging bits around is something that hardware is very good at doing cheaply. Arbitrary permutations basically boil down to renaming the inputs by shifting the output positions. While this is not exactly easy to implement for the general case, shifting or rotating bits, especially if the size of the object being rotated == the natural word size of the processor, is absolutely trivial. Even the naive implementation (selection tree ~5 clocks, forward, permute, issue) takes only 8 clocks, is easily pipelined, and takes marginal space.
Re:I work at a Linux-friendy company and....
on
Finding a Linux Job
·
· Score: 1
"2) Which edition of the "C programming Language" did you learn from? (trick question)"
What am I missing here? Why is this a trick question? I've always thought of it as a perfectly reasonable book to learn C from.
[off-topic] I feel really stupid about this, but I clicked on the link in this post's parent article without checking it. Don't bother; it's one of those Don Knotts trolls.
Pretty good idea, but you would need to salt the hash to ensure that one couldn't try a series of probable lines and match the hashed result with the known hashes. Moreover, you wouldn't probably need to include the line number and file name in the hash to prevent multiple occasions of the same line from confusing the patch. Perhaps this could be included as a part of the salt.
It [should] go without saying that this patent is pseudoscientific babble masquarading as a real invention that some patent examiner bought. Unfortunately, this is not very surprising considering what other, ahem, odd patents have been approved.
For example, numerous perpetual motion machines have been patented, as well as unlimited energy supplies and other such nonsense. These are really great for laughs on a rainy day when your own project is on the fritz. Of course, they never work, but this never seems to stop the USPTO from issuing the patents anyway. The laws of physics (and the gross violation thereof) don't seem to bother the patent office.
Did you even bother to read the article before spilling forth your uninformed garbage? Each Arizona registered voter is assigned a PIN which he or she must enter before his or her vote is counted, which brings about a host of other security and privacy concerns, but not the specific ones that you mentioned.
Possible problems include: -Interception of PIN numbers before delivery -"Birthday paradox" style attacks; one might accidentally run into a valid PIN, depending on how many combinations there are -Many opportunities for your ISP/random host on the Internet to gather information, if the voting isn't done via an encrypted link -Disparity in access between those of higher socioeconomic status and those for whom an Internet connection is less available (although people can still vote the traditional way) -Authentifying votes as valid, while preserving the privacy of individual voters. A blinded signature scheme (c.f. Chaum digital coins) might help solve this problem.
The NASA scientists use a laser-based system to detect fluctuations in the surface conditions that enable them to infer the existence of very large underground channels that could have been created by vast flows of water when Mars was much younger. As importantly, the information confirms that Mars used to be in a state of great geologic upheval, as demonstrated by the enormous latent volcanoes on the surface.
Very interesting article; this much water on a planet creates the prospect that life may have one day existed on Mars. Also, I think I might be pretty close to a first post. Oh well.
"Astronomers know that stars that form planetary nebulae produce a lot of carbon which is essential for life on Earth."
From the article. The actual production of carbon atoms isn't really big a deal. The carbon cycle that occurs inside the cores of stars has been known for at least several decades; its theoretical discovery won its originator the Nobel Prize. While it certainly is nice to have empirical confirmation of this theory, "life forming elements" is a rather misleading phrase. One could as easily assert that the "life forming elements" of hydrogen, nitrogen, and oxygen are being formed in our Sun now. It is the arrangement of these elements into complex structures that characterizes the formations of life.
The Wheeler-Burrow block sorting compression algorithm implemented in bzip2 does not "create a file with much more repetition in it." Rather, it takes advantage of the *heuristic* observation that on *most* of the files that people compress, adjacent bit strings will tend to clump more with certain bit strings than others. The block sorting algorithm itself produces an output with the exact same number of each byte as the input to the algorithm; the next phase in the algorithm uses a simple most-recently-used filter to create an output that will most likely have a substantially lower number of set bits than the input. A simple Huffman code is then used to compress this highly redundant output.
This notwithstanding, the simple fact remains that no algorithm can compress all possible inputs, regardless of what transformations are performed on it, out of simple uniqueness and distinguishibility considerations.
Slashdot Mirror
I have _The Story of Magic_ and the information is not nearly enough to implement a realistic attack on PURPLE. An appropiate analogy would be Feynman's "Six Easy Pieces" versus something like "The Large Scale Structure of Space-Time" by Ellis, Hawking or Misner, Thorne, Wheeler's "Gravitation." You would be able to handwave a description of gtr with the first one, but you wouldn't be able to anything quantitative. Likewise, _The Story of Magic_ leaves out the all-critical details about the reconstruction of the V->V and C->C tables.
The Enigma was only used for short-term tactical communications. The Army and Air Force version used 3 wheels, while the later naval versions used 4 wheels. All of the Enigma cryptosystems shared certain traits that made them especially amenable to a type of cryptanalysis known as the Index of Coincidence method (a letter could never be encrypted to its plaintext equivalent). There was never any real need to capture a naval Enigma, although if this occured, it would certainly have been a great help. Later German innovations, such as the plugboard and better keying techniques, made it more difficult for British cryptanalysts to break Enigma messages in useful durations of time. While there are indeed more than 3 extant Enigma machines, I believe that the article refers to 3 of a specific type and manufacture.
The details of the high-level encryption systems (such as the Lorentz cipher machines between German operational command and the leadership) have not ever been declassified yet, although it is known that they too were broken by the Allies. To this day, the details of how the Japanese PURPLE machine was broken are not known either. Rotor machines were used by the Allies as well during WWII, and by most nations until probably the late 1950s. It has additionally been rumored that codebreaking agencies had discovered astonishingly general techniques for breaking messages encrypted with rotor machines.
Compilers are certainly important, but I think even more important is the algorithm. It goes well beyond simple big-O complexity notation. To take the example of inverting a matrix, even though most classic algorithms are O(n^3), you have to take into consideration the cache characteristics of the algorithm used, the sparsity of the matrix, and other factors such as the specific form of the matrix and possible numerical instability. If your algorithm involves trig functions, or for that matter, division, in its innermost loop, you've probably got a big problem. I don't know of *any* processor with a division operation latency of under 8 clocks. It's probably time to reshuffle your implementation or pick a more suitable algorithm.
BTW, O(a^n) in standard notation is ill-defined, but would probably be interpreted as an exponential growth function with some arbitrary, but fixed, constant a. That places the problem squarely in the category of intractable. Although there are some very clever algorithms that can help in some cases (lattice basis reduction comes to mind).
"Here's a contrast to hopefully clarify it a bit: writing a program in machine code is typically 50x faster than letting a compiler generate it."
Bullshit. On most applications, good compiler generated code is not usually more than 60-70% slower than hand-tuned assembly. I've seen some exceptions to this general rule (ie. naive dot product vs. scheduled dot product on the x87 FPU stack), but the worst I've ever seen was about 8-10 times slower. Show me an application which gets a "50x" performance increase from writing the assembly yourself. Hell, just show me a code fragment from the kernel of the function, and I'll either show you why the code is either miserably written or I'll submit a patch to GCC to optimize for that case. That's a promise and you can hold me to it.
developer.intel.com has many good instruction reference guides in PDF format. I don't have any exact links, but try searching under "StrongARM Instruction Reference." I'm quite an advocate of the *ARM family; it's one of the few ISAs that is orthogonal enough that everything makes sense, and yet complete enough that you don't have to resort to crazy idiomic code fragments to get something useful done. If only Intel would give up their Pentium II's and use some of that great process technology on the StrongARMs :-).
What exact question is it that you are asking? The answer depends to a great extent upon the specifics of your problem. For some possible usage scenarios, here are my suggestions (disclaimer: I have a preference for SGI machines, because those are what I primarily use from day to day)
Standard office applications:Go for a cheap Celeron and lots of RAM. Most applications will be very responsive in any case.
3D games: an Athlon would probably be your best choice. Decent FPU performance, good integer performance, won't cost you a bundle. Most games don't really benefit from SMP anyway.
Render farms, other highly parallel, low internode communction applications: commodity x86 systems, the more the better.
RT control of other systems/experimental setups: I personally prefer the StrongARM series of processors for this role, since the price/performance is practically unmatched, the documentation is through, and programming in assembly for the SA is truly a joy compared to the hideous mess that is the x86. Only problem is that there no FPU (it does have an integer multiply though).
Data mining, data warehousing: I don't have any personal experience with these applications, but I have heard good things about Suns and the RS/6000's from IBM.
Single-threaded or low parallelism scientific computations: Definitely Alphas. They blow any other processor away on floating point intensive operations. The only real drawback is lack of CCNUMA/massively parallel shared-memory systems. IIRC, they top off at 8 or 16 processors.
Really big simultions, computational hydrodynamics, etc.: Keeping in mind my previous disclaimer, I would still have to suggest SGI Origin 2000 systems for this type of task. The out-of-box performance on a fully populated Origin 2000 is awe-inspiring. Another option might possibly be linked AS/400s or RS/6000s or even one of the Cray T3Es for vector oriented codes. A bit pricy, but if it's not your money...
This is utterly untrue. I can't even begin to imagine where you got this misinformation from. Did you just make it up because it sounded good? The absence of a license agreement does not indicate that the entity that holds the rights to the software has a)given up his or her rights to such software or b)that the user is not legally able to use the software. Precedent would suggest that the copyright holder retains the right to the software, although the entity would be unable to coerce a user of the software to abide by any retroactive license agreement. The user would be unable to use Be's intellectual property as his or her own, but would not be required to abide by, say a future clause against reverse engineering or decompilation of code.
I *think* this is a joke, since the article references "US Patent No. 45,487,338,209, 'A system for organizing user-submitted text by means of collaborative ranking' and US Patent No. 46,773,228,287." I am certain that the number of patents issues is below well below 46 billion. Another link in the article points to http://63.196.208.222/frameset.html (nominally PR Newswire, but check out the reverse DNS and dig on that IP) wherein it states that "According to intellectual property expert Rob Enderly of the Giga Information Group, the patent most likely to be asserted is 5,876,324." Apart from the rather fake sounding name, the disreprency in patent numbers makes me suspicious, as does the actual content of that patent (hint). Finally, at the bottom of that page, you have the story "Red Hat, VA Linux Systems in bidding war for "Harry Potter" series," an obviously fake April Fools Story. In conclusion, it seems to be a well-planned and well-executed joke. I commend them.
A reasonably accurate description of vector operations (or more accurately Single Instruction, Multiple Data operations), but is it truly necessary to bring in the linear algebra concept of a vector space? Strictly speaking, your defintion is not even entirely correct or complete. You define b and c as doubles, while b and c are formally scalar quantities; it is entirely acceptable for b and c to be defined over the scalar field of the complex numbers. Moreover, it is not entirely true that all vector spaces can be represented as an ordered list of numbers. For certain vector spaces, some structure (ie. existence of a inner product) is lost when the representation of the vector space is coerced into such a form. You also fail to present the closure properties of formal vector spaces with regard to scalar multiplication and addition as defined over the vector space. In the future, please karma whore in a more accurate fashion.
That's generally true, baring details about semantics and Karp reductions, but nobody has ever shown that factoring or the RSA problem is in NP-Complete! If somebody could demonstrate this, it would be quite a breakthrough in our understanding of the computational complexity of this problem and others related to the RSAP, like the DLP.
Knapsack PKC=based on knowing which subset of values in a given set will sum exactly to a certain fixed value (the size of the knapsack)
L^3 algorithm=Lenstra-Lenstra-Lovasz Lattice reduction algorithm; guaranteed to find a basis for a lattice with elements of length not more than a certain [theoretically exponential, but in practice only superpolynomial] length longer than the shortest basis for such a lattice. Used for reducing the lattice formed when inverting many knapsack PKC into a more easily handled size.
The following is a short summary of the effect that quantum computing will have on cryptography by type of cryptographic primitive, as is currently accepted by a consensus of cryptographers:
public key cryptosystems based on factoring or extracting discrete logs over a prime field- practical quantum computing will make these systems essentially useless, since the sender of the messages will have no inherent computational advantage over the attacker
public key cryptosystems based on discrete logs over eliptic curve- not much research has been done in this area, but it is not immediately apparent that quantum computing will nesessarily create a trivial break of this problem
public key cryptosystems based on knapsack problem- pretty much obselete already thanks to the L^3 lattice reduction algorithm; not much to worry about
public key cryptosystems based on calculations in a truncated polynomial ring modulo different small primes (ie. NTRU)- probably not much to worry about, as there is no apparent reduction from factoring to converting between different ring representations of a polynomial (the main attack is via the L^3 algorithm)
symmetric algorithms- square root reduction in brute force time
hash functions- theoretical square root reduction in time to find collisions; it isn't clear how to achieve this, though
general NP problems - surprisingly, recent results show that quantum computers may not be able to solve general problems in the space NP-Hard. Search on xxx.lanl.gov for a preprints about the (surprising relative lackof) Hamiltonian nonlinearity properties in quantum wave functions.
Actually, QC will make factoring large composites much easier than by a mere square root. Decomposition of large composites into primes can be done in NP-time; a QC will enable us to factor these composites in strictly polynomial time, whereas the best current factoring algorithms (NFS for general numbers, ECM for many medium sized factors) take subexponential time. The square root reduction applies to *conventional* symmetric encryption algorithms in the case of a brute force attack.
The original number is correct. 375 floating point operations per second is laughable. A pocket calculator can probably do better.
Excuse me? "Darn barrell shifters are so expensive in hardware"? Have you ever even seen a hardware VLSI design tool? Have you even heard of Verilog? In terms of hardware cost, a barrel shifter takes much less space than a fast carry-save or carry-branch adder. Flinging bits around is something that hardware is very good at doing cheaply. Arbitrary permutations basically boil down to renaming the inputs by shifting the output positions. While this is not exactly easy to implement for the general case, shifting or rotating bits, especially if the size of the object being rotated == the natural word size of the processor, is absolutely trivial. Even the naive implementation (selection tree ~5 clocks, forward, permute, issue) takes only 8 clocks, is easily pipelined, and takes marginal space.
"2) Which edition of the "C programming Language" did you learn from? (trick question)"
What am I missing here? Why is this a trick question? I've always thought of it as a perfectly reasonable book to learn C from.
1 isn't a prime number, as this would cause the natural numbers not to be a unique factorization domain.
[off-topic]
I feel really stupid about this, but I clicked on the link in this post's parent article without checking it. Don't bother; it's one of those Don Knotts trolls.
Pretty good idea, but you would need to salt the hash to ensure that one couldn't try a series of probable lines and match the hashed result with the known hashes. Moreover, you wouldn't probably need to include the line number and file name in the hash to prevent multiple occasions of the same line from confusing the patch. Perhaps this could be included as a part of the salt.
[off-topic]
Is this anti-aliased?
I'm impressed.
It [should] go without saying that this patent is pseudoscientific babble masquarading as a real invention that some patent examiner bought. Unfortunately, this is not very surprising considering what other, ahem, odd patents have been approved.
For example, numerous perpetual motion machines have been patented, as well as unlimited energy supplies and other such nonsense. These are really great for laughs on a rainy day when your own project is on the fritz. Of course, they never work, but this never seems to stop the USPTO from issuing the patents anyway. The laws of physics (and the gross violation thereof) don't seem to bother the patent office.
Did you even bother to read the article before spilling forth your uninformed garbage? Each Arizona registered voter is assigned a PIN which he or she must enter before his or her vote is counted, which brings about a host of other security and privacy concerns, but not the specific ones that you mentioned.
Possible problems include:
-Interception of PIN numbers before delivery
-"Birthday paradox" style attacks; one might accidentally run into a valid PIN, depending on how many combinations there are
-Many opportunities for your ISP/random host on the Internet to gather information, if the voting isn't done via an encrypted link
-Disparity in access between those of higher socioeconomic status and those for whom an Internet connection is less available (although people can still vote the traditional way)
-Authentifying votes as valid, while preserving the privacy of individual voters. A blinded signature scheme (c.f. Chaum digital coins) might help solve this problem.
The NASA scientists use a laser-based system to detect fluctuations in the surface conditions that enable them to infer the existence of very large underground channels that could have been created by vast flows of water when Mars was much younger. As importantly, the information confirms that Mars used to be in a state of great geologic upheval, as demonstrated by the enormous latent volcanoes on the surface.
Very interesting article; this much water on a planet creates the prospect that life may have one day existed on Mars. Also, I think I might be pretty close to a first post. Oh well.
"Astronomers know that stars that form planetary nebulae produce a lot of carbon which is essential for life on Earth."
From the article. The actual production of carbon atoms isn't really big a deal. The carbon cycle that occurs inside the cores of stars has been known for at least several decades; its theoretical discovery won its originator the Nobel Prize. While it certainly is nice to have empirical confirmation of this theory, "life forming elements" is a rather misleading phrase. One could as easily assert that the "life forming elements" of hydrogen, nitrogen, and oxygen are being formed in our Sun now. It is the arrangement of these elements into complex structures that characterizes the formations of life.
First post too, I think (4:23 PM EST, March 9)
The Wheeler-Burrow block sorting compression algorithm implemented in bzip2 does not "create a file with much more repetition in it." Rather, it takes advantage of the *heuristic* observation that on *most* of the files that people compress, adjacent bit strings will tend to clump more with certain bit strings than others. The block sorting algorithm itself produces an output with the exact same number of each byte as the input to the algorithm; the next phase in the algorithm uses a simple most-recently-used filter to create an output that will most likely have a substantially lower number of set bits than the input. A simple Huffman code is then used to compress this highly redundant output.
This notwithstanding, the simple fact remains that no algorithm can compress all possible inputs, regardless of what transformations are performed on it, out of simple uniqueness and distinguishibility considerations.