But somebody would have to be in idiot to buy these "hot" bitcoins because, as said previously, all transactions in the bitcoin network are public. They would then be bringing down law enforcement wrath on themselves because they are indistinguishable from the original hackers. And, again since transactions are public, everyone will know immediately which bitcoins were used in this ransom and hopefully will be smart enough not to accept them.
Executable files are slightly larger and there is no speed gain.
That depends on what applications you are running. Things that are math heavy can run significantly faster in 64-bit mode. As an example, RSA requires modular exponentiation of very large numbers. Algorithms to do this are comprised of a number of multiplications of equally large numbers. Since these numbers are on the order of 2048 bits, they need to be chunked into machine size blocks in order to actually do the multiplication. Having a 64-bit integer size already gives you at least a 2x speedup here because you have half as many blocks. Multiplication algorithms are also not quite linear (close to n log(n)) so it really gives you a bit more speed than that.
Maybe they had the UDIDs as part of an investigation into actual hackers/criminals (i.e. evidence), which would prevent them from commenting on it now. Just another possibility that seems more likely to me than the FBI somehow harvesting relatively useless phone IDs.
This technique lets you put arbitrary javascript in the page. I imagine there is some webmail with an exposed API you would be able to invoke via XMLHTTPRequest.
How is it a wonder? If there were 1300 VW beetles scattered around the globe, what is the chance you would ever wander upon one in your entire life? Earth orbit is a big place.
Yes but the difficulty is not linear, that is the whole point. If you can factor a 1024-bit number in x time, it should take 2*x to factor a 1025-bit number. That means that regardless of your current insecure bit length, if it has just now become insecure (i.e. we have just reached the technological level to factor keys of that length) you should be able to make it secure by adding a fixed number to the bit length (say 1024 bits, that seems to be the way we are going now). People didn't just jump from 2048 to 4096, there was a 3072 in between. There is no reason to continuously double your bit length except that you are being particularly paranoid. Now, this is all predicated on the assumption that a polynomial time factoring algorithm has not been found. If that is the case then it all goes out the window.
Another slightly problemwith encryption based on factoring it is more complicated than say AES because the keyspace is more nuanced. For AES the above holds wonderfully because for any key length n there are exactly 2^n possible keys and each of them is just as good as any other. For RSA, we only allow keys that are a product of two prime numbers. There are not so many of these in a given number range so with the same bit length n there will not be 2^n possible keys, but actually far fewer. Luckily, what is important is that the number of keys is exponential in n and we believe currently that primes are distributed something like 2^n/n in an n bit keyspace. This means that we lose a bit of security (this is the reason RSA keys are so much longer than comparably secure AES keys) but asymptotically we get the properties that we want.
I'm not sure how your comment is relevant to what I said. Quantum algorithms are not interesting for finding primes as we already have very fast classical algorithms for this. I was merely illustrating how our probabilistic classical algorithms are similar to Shor's because they both have one-sided error that we can efficiently limit by repeating the experiment. We even have a polynomial algorithm for primality testing which gives correct answers every time. Also, why do you say that the numbers we are interested in scale geometrically?
Thats how we find primes right now. All the practical algorithms are probabilistic. If a number is prime, running the algorithm always returns "prime". If it is composite, running the algorithm will result in "prime" about half the time and "composite" about half the time. This is fine, however, because we can run the algorithm n times and our confidence is.5^n, which grows very small very fast.
What kind of stupid advice is this? You can be the healthiest person in the world but you are going to need some medical attention if you slip on your front steps and crack your skull open. Accidents happen.
What the fuck man its like you don't even read the Wikipedia articles that you cite yourself. Italian Hall disaster in 1913, 73 dead. Give it up, you are wrong about the legal facts of the situation and your opinions are misguided to say the least.
If I pay somebody to kill my wife, all I did was "utter some words" but I am certainly guilty of conspiracy to commit murder. In the eyes of the law it is always about intent. Yelling fire cannot serve any purpose but to cause harm.
The second amendment also doesn't say anything about restricting which kinds of arms people can have, but you don't think it should be legal for people to buy surface to air missiles, do you?
Who ever said that the rampaging murderers should be let off the hook? No reason we can't spread the blame around when a person ends up dead because of malice or negligence. The point is that the original inciter either intended for people to get hurt or was woefully negligent in not realizing that people likely would be hurt in such a situation. Textbook murder/manslaughter.
Reading comprehension my good man, try it some time. The 1969 case overturned the original case, but not all implications of it. Speech is still illegal if it passes the "Brandenburg test" which is if the speaker intends to cause imminent lawlessness. That is precisely the case when yelling fire in a theater, and the Wikipedia article even says this about the concurring opinion (written by justice Douglas): "Finally, Douglas dealt with the classic example of a man "falsely shouting fire in a theater and causing a panic." In order to explain why someone could be legitimately prosecuted for this, Douglas called it an example in which "speech is brigaded with action." In the view of Douglas and Black, this was probably the only sort of case in which a person could be prosecuted for speech."
As it is now, not really because the hash is based only on OS and filesystem information which would all be copied when the drive is cloned. If, however, the key were instead derived from a hash of all your hardware IDs and what not then it would work. This is sort of what TPMs do for trusted boot and remote attestation. Unfortunately, those things are not hard for a determined adversary to spoof via virtual machine so you don't gain too much.
Due to the entropy loss in MD5, the algorithm itself adds characteristics to the output data. Some of these characteristics are compounded in iterative key stretching. Thus it's actually faster to do the key stretching to find the key than building a rainbow table for the last iteration -- the stretching itself helps build the characteristics that lead to hash collisions.
We're not trying to find collisions here, we are trying to find a preimage. As far as I know there are only theoretical attacks against MD5 that can do that (reduce complexity from 2^128 to 2^123). All the collision attacks (chosen-prefix and chosen-suffix) are attacks on a plaintext-ciphertext pair.
I'm old, lazy and patient. This is where I would start, not by finding the correct combinations of inputs, but brute forcing the MD5, or trying to pull out bits of the symmetric stream cipher via known plaintext attack -- It's encrypted machine code, it's going to have machine code in the payload.
Getting a few bits of the keystream is not helpful as all attacks on RC4 require either a large amount of the keystream or a number of messages encrypted with related keys. Even brute-forcing the hash in this case is hard because the domain is unknown. Perhaps the target program that it is looking for is in 10 nested directories with a 200 character long path. Because of the salts, this problem could actually be even harder than 2^128 because an input that you find that hashes to the correct value with the first salt will, with very high probability, not hash to the correct key when used with the second salt (unless you found the actual correct preimage and not a second preimage, which is unlikely if the domain actually is larger than 2^128).
The problem is that the specific program they are targeting is likely not known publicly. It could be a secret program developed by another country, which our intelligence services happen to know about through espionage but the public sector would not.
Not sure what you mean by variations. The problem is that hash functions are one-way or "preimage resistant", meaning that if they are secure then you cannot get any information about the input from only the output. Additionally, they have an avalanche property where small changes in the input produce large changes in the output. This makes it difficult to analyze hashes by tweaking the input piece by piece until you get the desired hash.
I could be confused about what you are suggesting, maybe you could clarify?
Slashdot Mirror
But somebody would have to be in idiot to buy these "hot" bitcoins because, as said previously, all transactions in the bitcoin network are public. They would then be bringing down law enforcement wrath on themselves because they are indistinguishable from the original hackers. And, again since transactions are public, everyone will know immediately which bitcoins were used in this ransom and hopefully will be smart enough not to accept them.
That is a good point. I googled it a bit and it seems as if it is the same however (3 cycles) on recent Intel hardware.
Executable files are slightly larger and there is no speed gain.
That depends on what applications you are running. Things that are math heavy can run significantly faster in 64-bit mode. As an example, RSA requires modular exponentiation of very large numbers. Algorithms to do this are comprised of a number of multiplications of equally large numbers. Since these numbers are on the order of 2048 bits, they need to be chunked into machine size blocks in order to actually do the multiplication. Having a 64-bit integer size already gives you at least a 2x speedup here because you have half as many blocks. Multiplication algorithms are also not quite linear (close to n log(n)) so it really gives you a bit more speed than that.
Maybe they had the UDIDs as part of an investigation into actual hackers/criminals (i.e. evidence), which would prevent them from commenting on it now. Just another possibility that seems more likely to me than the FBI somehow harvesting relatively useless phone IDs.
This technique lets you put arbitrary javascript in the page. I imagine there is some webmail with an exposed API you would be able to invoke via XMLHTTPRequest.
Sends it to you through a chain of anonymous remailers.
How is it a wonder? If there were 1300 VW beetles scattered around the globe, what is the chance you would ever wander upon one in your entire life? Earth orbit is a big place.
Except the price for gas will be so high by then that even with the increased efficiency it will be much more expensive to travel that it is today.
Yes but the difficulty is not linear, that is the whole point. If you can factor a 1024-bit number in x time, it should take 2*x to factor a 1025-bit number. That means that regardless of your current insecure bit length, if it has just now become insecure (i.e. we have just reached the technological level to factor keys of that length) you should be able to make it secure by adding a fixed number to the bit length (say 1024 bits, that seems to be the way we are going now). People didn't just jump from 2048 to 4096, there was a 3072 in between. There is no reason to continuously double your bit length except that you are being particularly paranoid. Now, this is all predicated on the assumption that a polynomial time factoring algorithm has not been found. If that is the case then it all goes out the window.
Another slightly problemwith encryption based on factoring it is more complicated than say AES because the keyspace is more nuanced. For AES the above holds wonderfully because for any key length n there are exactly 2^n possible keys and each of them is just as good as any other. For RSA, we only allow keys that are a product of two prime numbers. There are not so many of these in a given number range so with the same bit length n there will not be 2^n possible keys, but actually far fewer. Luckily, what is important is that the number of keys is exponential in n and we believe currently that primes are distributed something like 2^n/n in an n bit keyspace. This means that we lose a bit of security (this is the reason RSA keys are so much longer than comparably secure AES keys) but asymptotically we get the properties that we want.
I'm not sure how your comment is relevant to what I said. Quantum algorithms are not interesting for finding primes as we already have very fast classical algorithms for this. I was merely illustrating how our probabilistic classical algorithms are similar to Shor's because they both have one-sided error that we can efficiently limit by repeating the experiment. We even have a polynomial algorithm for primality testing which gives correct answers every time. Also, why do you say that the numbers we are interested in scale geometrically?
Thats how we find primes right now. All the practical algorithms are probabilistic. If a number is prime, running the algorithm always returns "prime". If it is composite, running the algorithm will result in "prime" about half the time and "composite" about half the time. This is fine, however, because we can run the algorithm n times and our confidence is .5^n, which grows very small very fast.
What kind of stupid advice is this? You can be the healthiest person in the world but you are going to need some medical attention if you slip on your front steps and crack your skull open. Accidents happen.
The original Bioshock on xbox360 only moved 2.53 million units worldwide, and we can assume a very low piracy rate as it was on Xbox 360 only.
What are you talking about? Bioshock was definitely released on PC at the same time.
Don't be an asshole, of course we are not talking about if there actually is a fire.
What the fuck man its like you don't even read the Wikipedia articles that you cite yourself. Italian Hall disaster in 1913, 73 dead. Give it up, you are wrong about the legal facts of the situation and your opinions are misguided to say the least.
If I pay somebody to kill my wife, all I did was "utter some words" but I am certainly guilty of conspiracy to commit murder. In the eyes of the law it is always about intent. Yelling fire cannot serve any purpose but to cause harm.
The second amendment also doesn't say anything about restricting which kinds of arms people can have, but you don't think it should be legal for people to buy surface to air missiles, do you?
Who ever said that the rampaging murderers should be let off the hook? No reason we can't spread the blame around when a person ends up dead because of malice or negligence. The point is that the original inciter either intended for people to get hurt or was woefully negligent in not realizing that people likely would be hurt in such a situation. Textbook murder/manslaughter.
Reading comprehension my good man, try it some time. The 1969 case overturned the original case, but not all implications of it. Speech is still illegal if it passes the "Brandenburg test" which is if the speaker intends to cause imminent lawlessness. That is precisely the case when yelling fire in a theater, and the Wikipedia article even says this about the concurring opinion (written by justice Douglas): "Finally, Douglas dealt with the classic example of a man "falsely shouting fire in a theater and causing a panic." In order to explain why someone could be legitimately prosecuted for this, Douglas called it an example in which "speech is brigaded with action." In the view of Douglas and Black, this was probably the only sort of case in which a person could be prosecuted for speech."
As it is now, not really because the hash is based only on OS and filesystem information which would all be copied when the drive is cloned. If, however, the key were instead derived from a hash of all your hardware IDs and what not then it would work. This is sort of what TPMs do for trusted boot and remote attestation. Unfortunately, those things are not hard for a determined adversary to spoof via virtual machine so you don't gain too much.
No because it loops over all path/program pairs so adding things will not break it. Only removing or renaming the target program will work.
Due to the entropy loss in MD5, the algorithm itself adds characteristics to the output data. Some of these characteristics are compounded in iterative key stretching. Thus it's actually faster to do the key stretching to find the key than building a rainbow table for the last iteration -- the stretching itself helps build the characteristics that lead to hash collisions.
We're not trying to find collisions here, we are trying to find a preimage. As far as I know there are only theoretical attacks against MD5 that can do that (reduce complexity from 2^128 to 2^123). All the collision attacks (chosen-prefix and chosen-suffix) are attacks on a plaintext-ciphertext pair.
I'm old, lazy and patient. This is where I would start, not by finding the correct combinations of inputs, but brute forcing the MD5, or trying to pull out bits of the symmetric stream cipher via known plaintext attack -- It's encrypted machine code, it's going to have machine code in the payload.
Getting a few bits of the keystream is not helpful as all attacks on RC4 require either a large amount of the keystream or a number of messages encrypted with related keys. Even brute-forcing the hash in this case is hard because the domain is unknown. Perhaps the target program that it is looking for is in 10 nested directories with a 200 character long path. Because of the salts, this problem could actually be even harder than 2^128 because an input that you find that hashes to the correct value with the first salt will, with very high probability, not hash to the correct key when used with the second salt (unless you found the actual correct preimage and not a second preimage, which is unlikely if the domain actually is larger than 2^128).
It loops over all path/program pairs so adding will not foil it, only removing or changing the specific one it is looking for.
The problem is that the specific program they are targeting is likely not known publicly. It could be a secret program developed by another country, which our intelligence services happen to know about through espionage but the public sector would not.
Not sure what you mean by variations. The problem is that hash functions are one-way or "preimage resistant", meaning that if they are secure then you cannot get any information about the input from only the output. Additionally, they have an avalanche property where small changes in the input produce large changes in the output. This makes it difficult to analyze hashes by tweaking the input piece by piece until you get the desired hash.
I could be confused about what you are suggesting, maybe you could clarify?