They need the "Police in free country crack down on their own people for idiotic reasons and abusing their authority thereby turning free country into a less-free country thereby aiding the terrorists" card.
Actually, that's how the terrorist player wins the game.
What I really meant is that when you talk about "steroids" in sports, you really mean "anabolic steroids". On the other hand, when you talk about steroids in medicine, you almost always mean corticosteroids (although anabolic steroids are occasionally used).
Steroids are a whole class of chemicals -- more than just anabolic and corticosteroids.
As I read it, the recent observations really just indicate that their previous thinking on solar system formation was flawed. This next iteration isn't empirically sound, it's just the next iteration.
Of course, scientists always want to know "well, what does this theory imply about what we should observe?" so they can test it.
Then, somehow, it magically becomes "scientists say Earth-like solar systems are rare".
Your criticism is certainly fair. The paper admits it's certainly a grey area, but from summary to summary the "importance" of their finding keeps increasing.
Extensive computer simulation from basic principles. Not, "well, this theory more closely matches what we've recently observed, so it's more accurate".
Believe it or not, logical weaknesses that can be caught by the Slashdot crowd are almost always noticed by scientists. It's just that Slashdot doesn't read the articles.
They're not actually determining that solar systems like ours are rare from the observations. The observations were incompatible with our current thinking on solar system formation. Solar system formation was reexamined, and a more-accuracy theory of solar system formation suggests that systems like ours are unlikely.
That's quite true. I'm not sure what your limitations are when working with the free-for-all segments (900 MHz and 2.4 GHz?). Certainly you can build some types of trivial radio-communication devices without a license (e.g., an RC car).
There are restrictions on home chemists, too. While you can legally obtain lots of chemicals and play around with them, I doubt most areas allow you to store a tank of hydrazine in your basement when you're in a residential area.
On the other hand, I don't actually know what kind of stuff he had (or they suspected or had evidence of him having) in his home lab.
I find ignorance to be basically politically agnostic. It's just that different political groups choose to be vocally ignorant about different matters.
If you're operating high-powered RF equipment, you're legally required to do it a certain distance from other people. There are a ton of rules about this.
For that matter, there are probably also laws against stockpiling hazardous chemicals in residential areas.
If you encrypted two different files, you'd have four sets of blocks, Ca, Pa, Cb, and Pb. Double-encryption produces three.
It's just that ways in which a specific implementation fails to protect the encryption method is a common, serious, and difficult-to-avoid possibility. If you're interested in having your encrypted file be secure and not playing games, you should assume an attacker knows everything about the encryption scheme, except for the key.
Both of these services are located on the wrong side of a hostile network and are woefully inaccurate when really understanding the content of the document is necessary.
Here's an example. It's avoidable, but don't take that as evidence that no other markers exist.
Suppose you're encrypting a single large file. A logical way for a program to do this is to create a temporary file, write the encrypted data to it as encryption proceeds, and then secure-wipe and delete the original file. (It's too large a file to hold in memory, and if you encrypt in-place, a failure during encryption will destroy the file.)
Bear in mind that many hard drives store, at the device level (not accessible to the OS but accessible to an investigator) a last-used time. Filesystems also do, to an extent.
So if you encrypt a file once, you write to a block of sectors C, then write to a block of sectors P. Both blocks have the same number of sectors, and the write times are within seconds of each other. If you encrypt twice, you write to a block of sectors C1, then write to a block P, then to a new block C2, then write over C1. All three blocks are the same length and have write times within a few seconds. C2 is the only file remaining, but it's clear from sector timestamps that you encrypted P twice.
For one, it's not at all an interesting approach if it only works for encrypting a single file.
For another, you're discounting the very real possibility that there is additional evidence in the situation that makes it apparent that it was done via this method.
Ah, ok, yes. However, that is the equivalent of encrypting with a double-size key and not telling anyone what algorithm you used. It should not be relied upon to provide any additional security, as you should assume the attacker knows the full details of your cryptographic system.
Even if the software you use has a "tag" that would let you check the validity of the outer-layer decryption, such a thing isn't theoretically required.
The problem is that you don't need to do one layer at a time in brute-forcing. If you encrypt with two keys, A and then B, what I do to brute force is try every possible pair of keys and check the validity of the resulting decrypted text. Now if my choice for key B is wrong, key A is decrypting garbage to garbage, but that's fine.
Now, if keys A and B are each 128 bits, then I have to try every possible pair of two 128-bit keys. There are 2^128 choices for a single 128-bit key, and there are 2^128 * 2^128 possible two-key pairs. 2^128*2^128=2^256, which is the number of different 256-bit keys. Two 128-bit keys equals one 256-bit key.
This is, incidentally, exactly what TripleDES does.
Encrypting twice with different keys is like encrypting once with a key that's twice as long (assuming your cryptosystem is good). It makes the result "much harder" to brute-force.
But, to be honest, nobody is going to be brute-forcing AES-256 anyway -- the weakness in modern security systems is not that the encryption can be brute-forced, it's everything else in the system.
What you're describing is a class of attack that is not necessarily shared among all systems of the same type. (It's possible to make magstripe systems that aren't vulnerable to replay attacks.)
Typical vulnerability disclosures are the details of how a particular system is vulnerable to a particular attack. Not "this system is probably vulnerable to some kind of replay attack", but how the system works and how the attack is applied to that system.
Slashdot Mirror
They need the "Police in free country crack down on their own people for idiotic reasons and abusing their authority thereby turning free country into a less-free country thereby aiding the terrorists" card.
Actually, that's how the terrorist player wins the game.
What I really meant is that when you talk about "steroids" in sports, you really mean "anabolic steroids". On the other hand, when you talk about steroids in medicine, you almost always mean corticosteroids (although anabolic steroids are occasionally used).
Steroids are a whole class of chemicals -- more than just anabolic and corticosteroids.
The governing bodies may not care, but anabolic steroids and the steroids used for medical treatments are very different.
As I read it, the recent observations really just indicate that their previous thinking on solar system formation was flawed. This next iteration isn't empirically sound, it's just the next iteration.
Of course, scientists always want to know "well, what does this theory imply about what we should observe?" so they can test it.
Then, somehow, it magically becomes "scientists say Earth-like solar systems are rare".
Eh, what can you do.
More a jab at the population at large. :-)
Your criticism is certainly fair. The paper admits it's certainly a grey area, but from summary to summary the "importance" of their finding keeps increasing.
Extensive computer simulation from basic principles. Not, "well, this theory more closely matches what we've recently observed, so it's more accurate".
Believe it or not, logical weaknesses that can be caught by the Slashdot crowd are almost always noticed by scientists. It's just that Slashdot doesn't read the articles.
They're not actually determining that solar systems like ours are rare from the observations. The observations were incompatible with our current thinking on solar system formation. Solar system formation was reexamined, and a more-accuracy theory of solar system formation suggests that systems like ours are unlikely.
That's quite true. I'm not sure what your limitations are when working with the free-for-all segments (900 MHz and 2.4 GHz?). Certainly you can build some types of trivial radio-communication devices without a license (e.g., an RC car).
There are restrictions on home chemists, too. While you can legally obtain lots of chemicals and play around with them, I doubt most areas allow you to store a tank of hydrazine in your basement when you're in a residential area.
On the other hand, I don't actually know what kind of stuff he had (or they suspected or had evidence of him having) in his home lab.
I'm not going to raid anyone's house, but those are much, much safer compounds than the sort of thing I'm thinking of.
I find ignorance to be basically politically agnostic. It's just that different political groups choose to be vocally ignorant about different matters.
If you're operating high-powered RF equipment, you're legally required to do it a certain distance from other people. There are a ton of rules about this.
For that matter, there are probably also laws against stockpiling hazardous chemicals in residential areas.
If you encrypted two different files, you'd have four sets of blocks, Ca, Pa, Cb, and Pb. Double-encryption produces three.
It's just that ways in which a specific implementation fails to protect the encryption method is a common, serious, and difficult-to-avoid possibility. If you're interested in having your encrypted file be secure and not playing games, you should assume an attacker knows everything about the encryption scheme, except for the key.
Both of these services are located on the wrong side of a hostile network and are woefully inaccurate when really understanding the content of the document is necessary.
Here's an example. It's avoidable, but don't take that as evidence that no other markers exist.
Suppose you're encrypting a single large file. A logical way for a program to do this is to create a temporary file, write the encrypted data to it as encryption proceeds, and then secure-wipe and delete the original file. (It's too large a file to hold in memory, and if you encrypt in-place, a failure during encryption will destroy the file.)
Bear in mind that many hard drives store, at the device level (not accessible to the OS but accessible to an investigator) a last-used time. Filesystems also do, to an extent.
So if you encrypt a file once, you write to a block of sectors C, then write to a block of sectors P. Both blocks have the same number of sectors, and the write times are within seconds of each other. If you encrypt twice, you write to a block of sectors C1, then write to a block P, then to a new block C2, then write over C1. All three blocks are the same length and have write times within a few seconds. C2 is the only file remaining, but it's clear from sector timestamps that you encrypted P twice.
For one, it's not at all an interesting approach if it only works for encrypting a single file.
For another, you're discounting the very real possibility that there is additional evidence in the situation that makes it apparent that it was done via this method.
Ah, ok, yes. However, that is the equivalent of encrypting with a double-size key and not telling anyone what algorithm you used. It should not be relied upon to provide any additional security, as you should assume the attacker knows the full details of your cryptographic system.
Even if the software you use has a "tag" that would let you check the validity of the outer-layer decryption, such a thing isn't theoretically required.
The problem is that you don't need to do one layer at a time in brute-forcing. If you encrypt with two keys, A and then B, what I do to brute force is try every possible pair of keys and check the validity of the resulting decrypted text. Now if my choice for key B is wrong, key A is decrypting garbage to garbage, but that's fine.
Now, if keys A and B are each 128 bits, then I have to try every possible pair of two 128-bit keys. There are 2^128 choices for a single 128-bit key, and there are 2^128 * 2^128 possible two-key pairs. 2^128*2^128=2^256, which is the number of different 256-bit keys. Two 128-bit keys equals one 256-bit key.
This is, incidentally, exactly what TripleDES does.
I suppose by "typical" you mean "old", since typical Unix machines these days use MD5 or better.
Encrypting twice with different keys is like encrypting once with a key that's twice as long (assuming your cryptosystem is good). It makes the result "much harder" to brute-force.
But, to be honest, nobody is going to be brute-forcing AES-256 anyway -- the weakness in modern security systems is not that the encryption can be brute-forced, it's everything else in the system.
What you're describing is a class of attack that is not necessarily shared among all systems of the same type. (It's possible to make magstripe systems that aren't vulnerable to replay attacks.)
Typical vulnerability disclosures are the details of how a particular system is vulnerable to a particular attack. Not "this system is probably vulnerable to some kind of replay attack", but how the system works and how the attack is applied to that system.
For the magstripe cards, I think all they're missing is how to compute the checksum.
That's the RFID vulnerability. They also disclose a magnetic stripe card vulnerability and various physical vulnerabilities.
You mean like the presentation that's on the DEFCON CDs?
You'll get in trouble for plenty of things, but not for messing around on the network.
There are no hackers at Defcon. It's clearly stated that it's social networking for ninjas. Everyone is a ninja.
Pay no attention to the content of the presentations or who is making them. :-)