It doesn't matter what software is on the other end. But the bill covers pieces of software. If you have an FTP client and an FTP server on your computer, no one piece of software on your computer provides all three capabilities necessary to classify it as a peer-to-peer file sharing client.
That's why the clever people that write these things make general policies, with the specifics to be interpreted on a per-case basis, rather than trying their hands at the rather foolish enterprise of attempting to enumerate every possible situation.
Only as a matter of scale. Before OS X was released, the Carbon libraries for OS 9 were released. Software that moved to these ran natively under both OS 9 and OS X. In a similar vein, most but not all XP-compatible software will run natively under Vista. For the software that doesn't, a VM-based compatibility system exists.
My own experience is only slightly applicable: I was in a Ph.D. program in Physics and left with a Master's. I'm now a programmer at an R&D company. You don't generally get hired here without an advanced degree. (As a Ph.D. student in the hard sciences, I was paid to go to grad school.)
I disagree that a Master's is worthless. If you're really interested in the subject and can do a research-oriented program, it's invaluable. It's a significant qualification point at higher levels -- to the point that it's common for people to go back to school to get one.
If you're not that interested in the subject, though, you won't get much out of a Master's, so I'm not sure it would go well for you.
It's actually fairly easy to jam GPS signals, so that the GPS receiver cannot get an accurate location fix. As long as you don't want to receive GPS signals in your own car, a jammer should take care of the problem.
You could also listen for the device's transmissions (assuming it's not instead designed to be retrieved later), which might be difficult and might not be.
A lot more goes into a security system than a private-key cryptographic algorithm. (Not to mention the need to account for the potential development of new attacks against your private-key algorithm.)
For example, your algorithm needs a key. How is it generated? Where is it stored? How long can you reasonably expect that key not to be lost?
Actually, a piece of software that tests all of the above -- except, probably, for bugs that cause it to malfunction -- is fairly trivial to put together.
Considering the purpose is to address people in industry who have software that runs on XP and not on Vista, I think the target customers have a fairly good idea of whether or not they need it.
One reason, to address the below, for not using VirtualPC-like technology is that it does differ significantly from using hardware virtualization, since you are forced to use emulated hardware. This can actually cause fairly significant compatibility problems
An interesting fact, yes -- although Windows 7's compatibility with Vista isn't the issue, it's its compatibility with XP. Try suggesting that Vista and XP are compatible.
Interesting though it may be, I don't see the point. The solution Microsoft is adding to Windows 7 for XP compatibility is, in fact, the same solution Apple used for OS 9 -> X.
Original commenter wanted to know why Microsoft isn't using the same approach Apple used, instead of this "hack solution". The answer is that Microsoft is.
For most systems, think about it in terms of the application developer. Say you encrypt a piece of e-mail with a password-based secret key. (Some function k(p) turns a password p into an n-bit key.) If you supply the wrong password, what should the system do? Usually you want the strength of the system to rest on the cryptography and not the inability to tell if a decryption was successful, so you simply include a marker to indicate if the decryption was successful. (There are standard padding and encoding schemes for this.)
Take an extreme mathematical case, though. Let's say I'm doing 128-bit AES, which operates on 16-byte blocks. Say I use no padding and have a 16-byte message. The decrypter will need to guess based on the properties of the mesage if the decryption worked. Even with only 16 bytes, if those bytes are English text, this is quite doable. If you've carefully chosen your messages so that all 16-byte messages are equally probable, then it's impossible, right? A test decryption e+k->p will produce a valid, reasonable plaintext, regardless of what the encrypted block e or key k are.
This is, incidentally, basically how TrueCrypt's deniable plausability works. The TrueCrypt headers are designed so that, in theory, every possible set of bytes is equally likely. The space the header would be stored in is filled with random data, which has the property that every possible set of bytes is equally likely. You then can't differentiate a block containing a header with one containing no header.
The solution Microsoft is adding to Windows 7 is the same solution Apple used for the OS 9 - X transition. Classic was a second operating system that ran essentially as a virtual machine.
I suppose it depends on your definition of "difficult" -- it's not particularly hard to find out if your processor supports virtualization extensions.
The Ars Technica is terrible -- it implies that it's a complete mystery why a virtualization system would require processor virtualization extensions to function.
I'm also not entirely sure it's reasonable to call a logical design decision you disagree with a "goof". I would hazard a guess that requiring virtualization extensions is intentional, not a mistake.
This has nothing to do with multiple hash algorithms. What you're referring to is that finding an n-way collision from a 2-way collision is polynomial time. That is, a 2-way collision is two documents with the same hash, and an n-way collision is n documents with the same hash.
Finding a pair of documents that have the same SHA1 hash doesn't help you find a pair of documents with the same MD5 hash. Indeed, none of the efficient-collision algorithms allow you to find collisions in both SHA1 and MD5 simultaneously. (Note that, as far as I know, there aren't even any efficient preimage attacks on MD5 or SHA1, only collision attacks.)
No, in proper cybersecurity, one should realize exactly that a particular protection mechanism is only likely to be secure for a limited period of time. There are even expected security times associated with different algorithms and key sizes.
This is why, for example, signing keys should only be valid for a limited period of time. It would be foolish to assume that it will remain secure forever, so it should be designed to become useless before it becomes insecure.
Says who? The order bars looking for "non-relevant" data, and even is so helpful as to list important categories for non-relevant data. System settings is not one of these. As has been illustrated here, system settings turn out to actually be quite relevant in some cases!
And it's not referring to your definition of peer-to-peer technology, it's providing a particular definition for peer-to-peer file-sharing software. Contrary to your reading of it, this is not software capable of transmitting files where, somewhere in the network, peer-to-peer design is used. (Though TCP is distincly not peer-to-peer. In some ways, IP can be considered such.)
First, there is substantial metadata, particularly outside the MP3 file, that can indicate the source of the file.
Second, in order for two ripped files to be identical, they need to be encoded using the same codec with the same settings. (MP3 is a format, not an algorithm for turning raw data into that format. Even with the same quality settings, there's no single way to convert raw data to MP3 -- each codec will do it slightly differently.)
Which would be more logical because how else can you tell the difference between a pirated MP3 and one I downloaded from Amazon.com or ripped from a CD?
Well, if you downloaded or shared it with LimeWire, internal files that record that the file was downloaded or shared and store its SHA1 hash might be a problem for you.
The order doesn't require them to identify music and other file types by extension. It is probably well within the limitations to use automated software to detect the file content.
Of course, if you were so foolish as to use an obviously-invented file extension and make a login/logout script, they would have two good reasons to investigate those files specifically, and additionally may report that you were attempting to conceal the files from a search.
American legal scholars, at least, claim that presumption of innocence was an established concept in ancient Rome, ancient Greece, and in the Old Testament (in addition to its present in England).
They are not peer-to-peer, they are client-server.
Using the bill's terms, see section 4, number 2. One of the two entities, the ssh server, performs (A) and (B) but not (C). The ssh client performs (B) and (C) but not (A).
Frankly, your definition of "peer to peer" is completely different from the actual definition. A peer-to-peer design differs from a client-server design. The majority of your examples -- Usenet, SMTP, FTP, rcp, rsync, ssh, etc. -- are client-server. (SMTP is peer-to-peer in theory between MTAs but not between a sender client and an MTA.)
And really, Napster "from the dawn of the Internet"? Hardly.
Slashdot Mirror
It doesn't matter what software is on the other end. But the bill covers pieces of software. If you have an FTP client and an FTP server on your computer, no one piece of software on your computer provides all three capabilities necessary to classify it as a peer-to-peer file sharing client.
This would explain why you are able to sue the police for harrassment, false imprisonment, etc.
That's why the clever people that write these things make general policies, with the specifics to be interpreted on a per-case basis, rather than trying their hands at the rather foolish enterprise of attempting to enumerate every possible situation.
Only as a matter of scale. Before OS X was released, the Carbon libraries for OS 9 were released. Software that moved to these ran natively under both OS 9 and OS X. In a similar vein, most but not all XP-compatible software will run natively under Vista. For the software that doesn't, a VM-based compatibility system exists.
The FTP client and server are independent pieces of software.
My own experience is only slightly applicable: I was in a Ph.D. program in Physics and left with a Master's. I'm now a programmer at an R&D company. You don't generally get hired here without an advanced degree. (As a Ph.D. student in the hard sciences, I was paid to go to grad school.)
I disagree that a Master's is worthless. If you're really interested in the subject and can do a research-oriented program, it's invaluable. It's a significant qualification point at higher levels -- to the point that it's common for people to go back to school to get one.
If you're not that interested in the subject, though, you won't get much out of a Master's, so I'm not sure it would go well for you.
You can't reasonably detect a GPS receiver. If the device continually transmits, though, you can detect that.
It's actually fairly easy to jam GPS signals, so that the GPS receiver cannot get an accurate location fix. As long as you don't want to receive GPS signals in your own car, a jammer should take care of the problem.
You could also listen for the device's transmissions (assuming it's not instead designed to be retrieved later), which might be difficult and might not be.
A lot more goes into a security system than a private-key cryptographic algorithm. (Not to mention the need to account for the potential development of new attacks against your private-key algorithm.)
For example, your algorithm needs a key. How is it generated? Where is it stored? How long can you reasonably expect that key not to be lost?
Actually, a piece of software that tests all of the above -- except, probably, for bugs that cause it to malfunction -- is fairly trivial to put together.
Considering the purpose is to address people in industry who have software that runs on XP and not on Vista, I think the target customers have a fairly good idea of whether or not they need it.
One reason, to address the below, for not using VirtualPC-like technology is that it does differ significantly from using hardware virtualization, since you are forced to use emulated hardware. This can actually cause fairly significant compatibility problems
An interesting fact, yes -- although Windows 7's compatibility with Vista isn't the issue, it's its compatibility with XP. Try suggesting that Vista and XP are compatible.
Interesting though it may be, I don't see the point. The solution Microsoft is adding to Windows 7 for XP compatibility is, in fact, the same solution Apple used for OS 9 -> X.
Original commenter wanted to know why Microsoft isn't using the same approach Apple used, instead of this "hack solution". The answer is that Microsoft is.
For most systems, think about it in terms of the application developer. Say you encrypt a piece of e-mail with a password-based secret key. (Some function k(p) turns a password p into an n-bit key.) If you supply the wrong password, what should the system do? Usually you want the strength of the system to rest on the cryptography and not the inability to tell if a decryption was successful, so you simply include a marker to indicate if the decryption was successful. (There are standard padding and encoding schemes for this.)
Take an extreme mathematical case, though. Let's say I'm doing 128-bit AES, which operates on 16-byte blocks. Say I use no padding and have a 16-byte message. The decrypter will need to guess based on the properties of the mesage if the decryption worked. Even with only 16 bytes, if those bytes are English text, this is quite doable. If you've carefully chosen your messages so that all 16-byte messages are equally probable, then it's impossible, right? A test decryption e+k->p will produce a valid, reasonable plaintext, regardless of what the encrypted block e or key k are.
This is, incidentally, basically how TrueCrypt's deniable plausability works. The TrueCrypt headers are designed so that, in theory, every possible set of bytes is equally likely. The space the header would be stored in is filled with random data, which has the property that every possible set of bytes is equally likely. You then can't differentiate a block containing a header with one containing no header.
The solution Microsoft is adding to Windows 7 is the same solution Apple used for the OS 9 - X transition. Classic was a second operating system that ran essentially as a virtual machine.
I suppose it depends on your definition of "difficult" -- it's not particularly hard to find out if your processor supports virtualization extensions.
The Ars Technica is terrible -- it implies that it's a complete mystery why a virtualization system would require processor virtualization extensions to function.
I'm also not entirely sure it's reasonable to call a logical design decision you disagree with a "goof". I would hazard a guess that requiring virtualization extensions is intentional, not a mistake.
This has nothing to do with multiple hash algorithms. What you're referring to is that finding an n-way collision from a 2-way collision is polynomial time. That is, a 2-way collision is two documents with the same hash, and an n-way collision is n documents with the same hash.
Finding a pair of documents that have the same SHA1 hash doesn't help you find a pair of documents with the same MD5 hash. Indeed, none of the efficient-collision algorithms allow you to find collisions in both SHA1 and MD5 simultaneously. (Note that, as far as I know, there aren't even any efficient preimage attacks on MD5 or SHA1, only collision attacks.)
Using multiple hash algorithms is helpful, yes.
No, in proper cybersecurity, one should realize exactly that a particular protection mechanism is only likely to be secure for a limited period of time. There are even expected security times associated with different algorithms and key sizes.
This is why, for example, signing keys should only be valid for a limited period of time. It would be foolish to assume that it will remain secure forever, so it should be designed to become useless before it becomes insecure.
Says who? The order bars looking for "non-relevant" data, and even is so helpful as to list important categories for non-relevant data. System settings is not one of these. As has been illustrated here, system settings turn out to actually be quite relevant in some cases!
And it's not referring to your definition of peer-to-peer technology, it's providing a particular definition for peer-to-peer file-sharing software. Contrary to your reading of it, this is not software capable of transmitting files where, somewhere in the network, peer-to-peer design is used. (Though TCP is distincly not peer-to-peer. In some ways, IP can be considered such.)
You don't need antiterrorism laws -- laws against destruction of evidence and setting dangerous traps will make your life difficult enough.
First, there is substantial metadata, particularly outside the MP3 file, that can indicate the source of the file.
Second, in order for two ripped files to be identical, they need to be encoded using the same codec with the same settings. (MP3 is a format, not an algorithm for turning raw data into that format. Even with the same quality settings, there's no single way to convert raw data to MP3 -- each codec will do it slightly differently.)
Which would be more logical because how else can you tell the difference between a pirated MP3 and one I downloaded from Amazon.com or ripped from a CD?
Well, if you downloaded or shared it with LimeWire, internal files that record that the file was downloaded or shared and store its SHA1 hash might be a problem for you.
The order doesn't require them to identify music and other file types by extension. It is probably well within the limitations to use automated software to detect the file content.
Of course, if you were so foolish as to use an obviously-invented file extension and make a login/logout script, they would have two good reasons to investigate those files specifically, and additionally may report that you were attempting to conceal the files from a search.
American legal scholars, at least, claim that presumption of innocence was an established concept in ancient Rome, ancient Greece, and in the Old Testament (in addition to its present in England).
They are not peer-to-peer, they are client-server.
Using the bill's terms, see section 4, number 2. One of the two entities, the ssh server, performs (A) and (B) but not (C). The ssh client performs (B) and (C) but not (A).
Frankly, your definition of "peer to peer" is completely different from the actual definition. A peer-to-peer design differs from a client-server design. The majority of your examples -- Usenet, SMTP, FTP, rcp, rsync, ssh, etc. -- are client-server. (SMTP is peer-to-peer in theory between MTAs but not between a sender client and an MTA.)
And really, Napster "from the dawn of the Internet"? Hardly.
How about reading the article?