It should be clear that finding evidence these developments would not have occurred is difficult and highly subjective at best.
What you should do, as a first attempt, is compare the NASA budget to the number and impact of developments that occur as a result of the NASA budget, for an "invention efficiency". I'd also look at the amount of money they spend specifically on research with the impact of their research developments. Compare this with similar number for government-funded research, private industry in general, and industry-funded research for a measure of how useful NASA is in generating scientific and engineering developments.
You do realize that the President isn't really responsible for the regulation of banks or the federal reserve, and certainly doesn't have any influence beyond government regulation on how banks operate.
SSL isn't really broken. There's one attack against it. It was already known that the attack was possible, the only question was the difficulty. As it stands, reproducing their work is fairly difficult. There's also a quite effective mitigation -- don't accept certificates where any elements of the certificate chain other than pre-trusted root certs use only MD5 as their hash algorithm.
The domain has to be registered to someone, and the path to companies who hold the "someone" information can be made trusted. You don't have to issue a whois query and hope that the information hasn't been tainted.
For the issuing of SSL certificates, which essentially protect against network-level hacks, being susceptible to network-level hacks is a pretty big deal.
Kaminsky's DNS attack -- and the BGP hack, for that matter -- demonstrate pretty clearly why being able to masquerade as a particular host to the CA is not sufficient to prove you are actually the proper owner of that domain.
Actually, a General Products hull won't save you. Cars already are less strong than the could be, because their squishy contents are too susceptible to high acceleration. A perfectly rigid car body would just kill its passengers.
Not at all, depending on your false positive rate and the predictability of the false negatives. If false negatives are random and you don't let people who are marked as "dangerous" leave and try again, you don't need your false negative rate to be that low -- it still presents a very significant problem to a potential attacker.
False positives, on the other hand, are a big problem. The enormous majority of people are negatives, so with any appreciably large false positive rate, nearly all positives will be false. You then need a secondary system to separate real positives from false -- otherwise all you're doing is marking lots of random people as dangerous.
Granted, all they cite is their "accuracy", which is ambiguous -- it's neither a false positive nor false negative rate.
Yeah, I glanced over their paper again to see if there was something convenient to quote. If you're not familiar with existing MD5 attacks, the abstract is not too clear on this point.
You really should read the original paper -- or have some understanding of developments in cryptography. They "generated" two certificates with identical MD5 hashes and got a CA to produce an MD5-only signature for the one. Since the hashes are the same, the signature's good for both. This absolutely requires being able to manipulate both certificates.
They don't actually produce the first certificate themselves -- the CA does. However, the CA they chose generates the cert automatically from data they provide in a highly predictable fashion, which allows them to, in practice, supply the cert to be signed.
This, incidentally, is terrible cryptographic practice -- performing functions like signature generation or encryption on arbitrarily-supplied data automatically, as it is a requirement for many attacks. If the CA introduced 128 bits of unpredictable entropy into each issued cert, their method would be completely worthless, even with the insecurity of MD5, because guessing the added message entropy is too difficult.
To be more specific: if any certificate in the chain has both been issued by a CA (that is, it is not included in your list of "trusted certificates") and its signature includes only an MD5 hash, it is untrustworthy.
So far there is no known method for creating a string with a specified MD5 hash. In this regard, the only advantage SHA1 has over MD5 is hash length.
There are other serious problems that people seem to ignore over MD5's weakness. These CAs are not only not really doing much identity validation, they're violating a major cryptographic principle -- they are simply automatically signing data that is directly generated from user-supplied data. Having predictable serial numbers, validity times, and fields that can contain large amounts of arbitrary data is what allows this attack to work in the first place.
It depends on if you are trying to produce two strings with the same hash or trying to produce one string with a predetermined hash. The former can be done faster, but is not brute force. (This is "the weakness" of MD5.) The latter still can only be brute-forced.
To answer the Orwellian concerns, it's entirely possible to implement this without telling the state when or where you are driving -- only how much in-state driving you did in between gas fillups. (Only slightly more information than they would have obtained anyway, assuming they have access to when and how much gas you purchase.) The GPS can track and sum in-state driving and report it to the gas station upon fillup. The capacity to store more information, report it to the state, or otherwise track your movements doesn't even have to be built in. On first look, that appears to be roughly their plan.
On the other hand, they certainly could set up the future capacity to track your travel. Further, if they don't constantly track you, there's relatively little reason for the state to actually trust the output of your GPS unit. Since it's entirely under your control in between fillups, a motivated attacker could control the system. (A really motivated attacker would sell their modifications to less-clever drivers.)
Of course, I still think the system is stupid. High-efficiency vehicles don't have enough market penetration to really worry about this, so a higher tax on low-efficiency vehicles is still reasonable. The plan sounds expensive to implement and prone to failure. It's hard to cheat a gas tax.
What matters is not what hash is used in the root, but what algorithm newly-issued certificates can be hashed with. If the CA can be convinced to issue a certificate hashed with MD5, then it is susceptible to this attack. If newly-issued certs must use SHA1 or better, than it is not susceptible, even if the root certificate is hashed with MD5.
(Moreover, one could imagine that there is a root cert signed with SHA1, but the CA issues MD5-signed certs. This would also be vulnerable.)
Fortunately -- and not at all surprising, if you follow cryptography -- this attack requires that you craft two certs and get the CA to sign one. Computing a collision against a preexisting cert is still infeasible.
No, it needs to be a CA that is issuing certificates with MD5, not a CA whose certificate is signed by MD5. With this attack, already-created certificates are not vulnerable.
You have no clue what you're talking about. Rainbow tables are only useful for small inputs, and work regardless of the hashing function.
MD5 collisions have been computable, but it's only really reasonable to produce two strings with the same MD5 hash -- not to produce a single string with a given MD5 hash.
Since MD5 is 128 bits, if computing a collision takes on the order of 2^128 attempts, it is indeed brute force and is not a weakness of MD5 at all. A weakness is a property that allows you to perform some undesirable action -- say, compute a collision -- faster than absolute brute force.
Compromising the security of a system isn't sufficient to classify software as malware. If it were, the majority of the software on a system, including its operating system, might be considered malware.
Malware is generally classified as such by intent. While plenty of people may not agree with the Sony's intent, myself included, I think it's quite distinct from the intent of real malware. Malware generally does some combination of performing communications against your consent, harvesting personal data and storing or transmitting it against your consent, intentionally and maliciously rendering your computer or data unusable, and exploiting security vulnerabilities to perform actions the malware would not normally be privileged to perform.
What a rootkit is depends on who you ask. The earlier definition is that it is software that performs privilege escalation -- so would always or almost always be malware. To my knowledge, the Sony software doesn't do this. The modern definition is that it is software that uses privileged operations to conceal itself from the user and the system. The Sony rootkit does do this, as do a number of debugging and anti-malware tools.
The unpacker code behaves differently if it is being monitored.
An antivirus program cannot simply unpack the data through manipulation, as the packing can include arbitrary coding. (Technically yes, it could, but it is unreasonable to.) The antivirus program has to run the unpacking code if it wants to examine the unpacked data. It could emulate a system itself (which would really be unpacking by manipulation only), which is nearly impossible to do well enough that it is undetectable; it could simply execute the code, which makes interrupting it while it's in a state that it can be analyzed and before it's done any damage very difficult; or, it could run it while monitoring it, which is detectable, but not very easily so.
Of course, if an antivirus could reliably block everything that would allow in-process code exploits and then consult a signature oracle to determine if the process is malicious, it should. Things aren't so simple, though.
Frankly, static analysis, despite its popularity, sucks. It's fairly trivial to sneak unpacked malware past static analyzers.
Oh, they don't. But the evil unpacker can do something like check the state of the debug registers, which is one way an antivirus can examine the unpacked code without simply allowing it to execute. They can then change their behavior based on whether or not the unpacker is being debugged. They can do this in fairly subtle ways, and can do it for the common methods of inspecting executables.
Putting your antivirus in the hypervisor and using VM introspection to do the inspection is the current silver bullet, as detecting this is rather tricky. (Currently possible only with timing attacks if your hypervisor doesn't want to be detected. Moreover, malware that won't run if it's in a VM is not so useful if VMs become more common.)
Slashdot Mirror
It should be clear that finding evidence these developments would not have occurred is difficult and highly subjective at best.
What you should do, as a first attempt, is compare the NASA budget to the number and impact of developments that occur as a result of the NASA budget, for an "invention efficiency". I'd also look at the amount of money they spend specifically on research with the impact of their research developments. Compare this with similar number for government-funded research, private industry in general, and industry-funded research for a measure of how useful NASA is in generating scientific and engineering developments.
You do realize that the President isn't really responsible for the regulation of banks or the federal reserve, and certainly doesn't have any influence beyond government regulation on how banks operate.
SSL isn't really broken. There's one attack against it. It was already known that the attack was possible, the only question was the difficulty. As it stands, reproducing their work is fairly difficult. There's also a quite effective mitigation -- don't accept certificates where any elements of the certificate chain other than pre-trusted root certs use only MD5 as their hash algorithm.
Actually, it's mostly popular to get bank credentials directly from the user's machine via malware. Jacking SSL isn't as successful.
The domain has to be registered to someone, and the path to companies who hold the "someone" information can be made trusted. You don't have to issue a whois query and hope that the information hasn't been tainted.
For the issuing of SSL certificates, which essentially protect against network-level hacks, being susceptible to network-level hacks is a pretty big deal.
Kaminsky's DNS attack -- and the BGP hack, for that matter -- demonstrate pretty clearly why being able to masquerade as a particular host to the CA is not sufficient to prove you are actually the proper owner of that domain.
That was actually the stasis field they used. That was not a stock feature of the General Products hull. :-)
Yes, the stasis field does fix that issue.
Actually, a General Products hull won't save you. Cars already are less strong than the could be, because their squishy contents are too susceptible to high acceleration. A perfectly rigid car body would just kill its passengers.
Wal-Mart doesn't have a suggestion box?
I'm sure Google lawyers haven't thought to search patents and applications for submitted ideas before the company pays to implement them.
Also, most ideas that you would put in suggestion boxes aren't sufficient to patent.
Not at all, depending on your false positive rate and the predictability of the false negatives. If false negatives are random and you don't let people who are marked as "dangerous" leave and try again, you don't need your false negative rate to be that low -- it still presents a very significant problem to a potential attacker.
False positives, on the other hand, are a big problem. The enormous majority of people are negatives, so with any appreciably large false positive rate, nearly all positives will be false. You then need a secondary system to separate real positives from false -- otherwise all you're doing is marking lots of random people as dangerous.
Granted, all they cite is their "accuracy", which is ambiguous -- it's neither a false positive nor false negative rate.
Yeah, I glanced over their paper again to see if there was something convenient to quote. If you're not familiar with existing MD5 attacks, the abstract is not too clear on this point.
You really should read the original paper -- or have some understanding of developments in cryptography. They "generated" two certificates with identical MD5 hashes and got a CA to produce an MD5-only signature for the one. Since the hashes are the same, the signature's good for both. This absolutely requires being able to manipulate both certificates.
They don't actually produce the first certificate themselves -- the CA does. However, the CA they chose generates the cert automatically from data they provide in a highly predictable fashion, which allows them to, in practice, supply the cert to be signed.
This, incidentally, is terrible cryptographic practice -- performing functions like signature generation or encryption on arbitrarily-supplied data automatically, as it is a requirement for many attacks. If the CA introduced 128 bits of unpredictable entropy into each issued cert, their method would be completely worthless, even with the insecurity of MD5, because guessing the added message entropy is too difficult.
To be more specific: if any certificate in the chain has both been issued by a CA (that is, it is not included in your list of "trusted certificates") and its signature includes only an MD5 hash, it is untrustworthy.
So far there is no known method for creating a string with a specified MD5 hash. In this regard, the only advantage SHA1 has over MD5 is hash length.
There are other serious problems that people seem to ignore over MD5's weakness. These CAs are not only not really doing much identity validation, they're violating a major cryptographic principle -- they are simply automatically signing data that is directly generated from user-supplied data. Having predictable serial numbers, validity times, and fields that can contain large amounts of arbitrary data is what allows this attack to work in the first place.
It depends on if you are trying to produce two strings with the same hash or trying to produce one string with a predetermined hash. The former can be done faster, but is not brute force. (This is "the weakness" of MD5.) The latter still can only be brute-forced.
To answer the Orwellian concerns, it's entirely possible to implement this without telling the state when or where you are driving -- only how much in-state driving you did in between gas fillups. (Only slightly more information than they would have obtained anyway, assuming they have access to when and how much gas you purchase.) The GPS can track and sum in-state driving and report it to the gas station upon fillup. The capacity to store more information, report it to the state, or otherwise track your movements doesn't even have to be built in. On first look, that appears to be roughly their plan.
On the other hand, they certainly could set up the future capacity to track your travel. Further, if they don't constantly track you, there's relatively little reason for the state to actually trust the output of your GPS unit. Since it's entirely under your control in between fillups, a motivated attacker could control the system. (A really motivated attacker would sell their modifications to less-clever drivers.)
Of course, I still think the system is stupid. High-efficiency vehicles don't have enough market penetration to really worry about this, so a higher tax on low-efficiency vehicles is still reasonable. The plan sounds expensive to implement and prone to failure. It's hard to cheat a gas tax.
What matters is not what hash is used in the root, but what algorithm newly-issued certificates can be hashed with. If the CA can be convinced to issue a certificate hashed with MD5, then it is susceptible to this attack. If newly-issued certs must use SHA1 or better, than it is not susceptible, even if the root certificate is hashed with MD5.
(Moreover, one could imagine that there is a root cert signed with SHA1, but the CA issues MD5-signed certs. This would also be vulnerable.)
Fortunately -- and not at all surprising, if you follow cryptography -- this attack requires that you craft two certs and get the CA to sign one. Computing a collision against a preexisting cert is still infeasible.
No, it needs to be a CA that is issuing certificates with MD5, not a CA whose certificate is signed by MD5. With this attack, already-created certificates are not vulnerable.
You have no clue what you're talking about. Rainbow tables are only useful for small inputs, and work regardless of the hashing function.
MD5 collisions have been computable, but it's only really reasonable to produce two strings with the same MD5 hash -- not to produce a single string with a given MD5 hash.
Since MD5 is 128 bits, if computing a collision takes on the order of 2^128 attempts, it is indeed brute force and is not a weakness of MD5 at all. A weakness is a property that allows you to perform some undesirable action -- say, compute a collision -- faster than absolute brute force.
Compromising the security of a system isn't sufficient to classify software as malware. If it were, the majority of the software on a system, including its operating system, might be considered malware.
Malware is generally classified as such by intent. While plenty of people may not agree with the Sony's intent, myself included, I think it's quite distinct from the intent of real malware. Malware generally does some combination of performing communications against your consent, harvesting personal data and storing or transmitting it against your consent, intentionally and maliciously rendering your computer or data unusable, and exploiting security vulnerabilities to perform actions the malware would not normally be privileged to perform.
What a rootkit is depends on who you ask. The earlier definition is that it is software that performs privilege escalation -- so would always or almost always be malware. To my knowledge, the Sony software doesn't do this. The modern definition is that it is software that uses privileged operations to conceal itself from the user and the system. The Sony rootkit does do this, as do a number of debugging and anti-malware tools.
The unpacker code behaves differently if it is being monitored.
An antivirus program cannot simply unpack the data through manipulation, as the packing can include arbitrary coding. (Technically yes, it could, but it is unreasonable to.) The antivirus program has to run the unpacking code if it wants to examine the unpacked data. It could emulate a system itself (which would really be unpacking by manipulation only), which is nearly impossible to do well enough that it is undetectable; it could simply execute the code, which makes interrupting it while it's in a state that it can be analyzed and before it's done any damage very difficult; or, it could run it while monitoring it, which is detectable, but not very easily so.
Of course, if an antivirus could reliably block everything that would allow in-process code exploits and then consult a signature oracle to determine if the process is malicious, it should. Things aren't so simple, though.
Frankly, static analysis, despite its popularity, sucks. It's fairly trivial to sneak unpacked malware past static analyzers.
More to the point, in what cases has their patent actually been used against other companies?
Oh, they don't. But the evil unpacker can do something like check the state of the debug registers, which is one way an antivirus can examine the unpacked code without simply allowing it to execute. They can then change their behavior based on whether or not the unpacker is being debugged. They can do this in fairly subtle ways, and can do it for the common methods of inspecting executables.
Putting your antivirus in the hypervisor and using VM introspection to do the inspection is the current silver bullet, as detecting this is rather tricky. (Currently possible only with timing attacks if your hypervisor doesn't want to be detected. Moreover, malware that won't run if it's in a VM is not so useful if VMs become more common.)