Sorry, yes, I meant watt-hours, not kilowatt-hours. It was a think-o. I did the calculations several years ago, and I didn't bother to go look them up again when I posted this morning. It's probably time to redo them anyway, as CPUs are now much more energy efficient than they were back then.
The point is that the amount of fuel being burned to re-confirm a statistical theory was staggering. We knew it would take roughly X tests to crack a DES key, and it did. Proving it once was exciting. We knew it would take Y tests to crack an RC4-56 key, and it did. Proving that was somewhat less exciting. There was no point in burning up further fuel just to prove that we could crack an RC5-64 key in Z tests. Fine, we know it'll work, save the damn fuel.
The last time I measured the difference between an Athlon 2400 CPU sitting idle at a Windows explorer desktop (somewhere around 3% CPU usage) and the same CPU with its load peg at 100%, the difference was 60 Watts extra.
The reason I went looking was because I had installed distributed.net's cracker on one day, and the next when I went into the room I noticed that it was uncomfortably warmer than the previous day. So I used my battery backup's internal statistics to measure current draw, and I was very surprised to see the delta. I've since confirmed similar behavior with my latest desktop using a Kill-A-Watt, but I don't remember the exact numbers for load vs. idle.
Nothing is an absolute in cryptography. You still have to make guesses as to when you hit upon the correct answer. And an adversary has every incentive to not make it easy for you.
But the adversary might be lazy, and let the tools do their jobs by default. When they decrypt their archive, they probably want to immediately use the results without going through a second deobfuscation step. Never discount the value of human nature and laziness -- they could save you tons of work.
As a cryptanalyst, you have to look for shortcuts. If I were given foo.7z and was told it was encrypted, I'd only have a few formats to try. It could be a bare 7z format (described here, or a compressed version. I'd have to figure out what possible artifacts I could look for in the decrypted file. But knowing it's in 7z format makes the job easier. (Of course, 7zip's key strengthening routine would not make it easier, as the key is encrypted 2^18 times!)
I'm not saying it's easy. There are thousands of file formats in common use out there. And I'd have only hope that the adversary is using one of them. But it's really not much different of a problem than "magic" already solves. And I could probably leverage a.magic file to help with the identification task.
A "known plaintext attack" is a specific cryptographic technique where you use known plaintext material to help break the key. A very simple example might be a Caesar cypher where you know the word ROME is in the message. You could then try subtracting the values of ROME against the letters in the message BUUBD LSPNF, and you'd quickly find the last four letters where the differences are all -1,-1,-1,-1, thus the key is to shift each letter by one, yielding the message ATTACK ROME. Without the plaintext you'd have to solve the cypher the old fashioned way.
The ULTRA project who decrypted Enigma didn't use a known plaintext attack either. They couldn't reverse engineer the keys from the cribs they obtained. Instead, they used the cribs to solve a different problem (which happens to be the same problem I'm describing.) They had to put in "stop words" to get the bombes to mechanically stop spinning when they encountered a possible solution.
What I described is not a known plaintext attack. It is simply testing the output of the algorithm against possible solutions. No algorithm is hardened against this because this is the normal function of the cypher.
It wasn't carbon, but the fuel consumed that was my first thought. Back when distributed.net was busy burning energy to win these pointless challenges, I did some rough calculations on the electricity required to solve it.
Turns out that the energy spent breaking RC5-64 used somewhere between 2 and 50 *trains* full of coal.
And that was only the energy directly consumed by the computers involved, and not any of the heating or cooling costs associated with it. And sure, more modern CPUs are more energy efficient, and I extrapolated the figures from a lot of published sources and made a lot of assumptions. But regardless of CO2 or greenhouse gasses or dirty coal or any of that environmental stuff, that's a lot of irreplaceable fossil fuel that's now gone.
I don't think it's sad or tainted to consider the overall impact of what you do. Saying "oh, I want to help search for E.T." is one thing. It may cost you an extra 1440 kWh/day, but you have the money, no big deal. But understanding that SETI@HOME is causing tens of thousands of people around the globe to collectively burn tons of fuel every day might make some of the volunteers rethink their decision. Ignoring that is the kind of perspective that thoughtlessly sucks up our finite resources.
And no, I don't consider alien hunting a valuable use of energy, at least not at this time in our history. Once we have fusion reactors or some other form of "free energy", all that will change.
Go ahead and crack keys, search for Extra Terrestrials, or fold proteins, or whatever you want to do with your box. Leave your lights on 24x7. Run the furnace and the air conditioner together. Just understand that what you do today has an impact, and consider the value of the outcome.
That's only a problem if you have no idea what the encrypted data might be. But in most reality-based cases, that's not the problem. You almost always have the clues you need.
In this case, for example, the file is a ZIP archive. That means the archive contains in the clear the original file names including any extensions, such as.jpeg,.bmp,.doc,.pdf, or whatever. All those file types have artifacts you can test for. They all have specific formats. They'll have version numbers, dimensions that must fall within reasonable boundaries, or other attributes that simply won't produce a coherent file unless they're correct.
For example, a JPEG image file is a container and is filled with markers identifying all the different sections. They all must be right or it won't display. So you'd start by looking for the SOI marker as the first byte of the file (0xffd8) or you'd throw it out. After the SOI you'd have to find another valid JPEG marker (two more bytes beginning with 0xFF.) So that's three bytes you'd have to match exactly, and the fourth byte would have to be on the list of valid markers. After you find the next marker, it'll probably be followed by a length (two or four more bytes). If that length is greater than your file size, it's a fail. Sure, if all that passes you'd have to decrypt more data to figure out if you're still in a valid file, but the chances are now only about 1 in 16 million keys tested. You then farm all these "potentials" to a machine or other process dedicated to deeper examination of the candidates.
If I were writing this, I'd have enough smarts in the key tester to look for all possibilities within the first blocksize of the cypher. Anything that looked reasonable at that point would be exported to the "evaluate potentials" system.
Every data file has its structure. You just have to look for it.
What, you don't know how to set the clock on your computer back to June 1st, then fire up Word and type up the document? That amount of effort certainly doesn't take a techie or a fancy bit editor. It only takes a few drops of imagination. It's certainly within the skillset of your average cop.
The only requirement is that you set the clock back before creating the new doc. It won't work to set the clock back and try to edit it after the doc has been created. But in that case you'd just have to create another new doc and retype in the old text. It's no big deal, but when people are stressed out enough that they're forging "evidence" they're also likely in a rush, and may make a careless mistake.
But the complexity could be managed, or even used. Perhaps with a more capable set of devices I could create "context aware profiles." When I'm home, maybe I want the phone functions to ring the house cordless extensions for my family phone list and the phone's audio stream to go to the stereo, unless the TV is on. It might be difficult or complex to set up, but I could do the configuration on a browser through some clever UI, and tell it to store my wi-fi profile rules on the "me" device (probably my phone), which would share them with all the rest of my devices on demand. The phone would then follow the rules to figure out which profile applies in which scenarios.
That'd be really cool. If the GPS device says "at work", the profile would be silent ringing. If the calendar event category is "important", it would send the callers to voicemail. And I would carry all that stuff automatically with the phone.
While I really like the profiles and the interoperability, the more devices that you get in your "circle of stuff" the harder it is to have all your devices continue to default to doing the "right thing".
With one phone, one headset, one computer, one handheld, it's pretty simple. With multiple phones sharing a single hands-free provider (as might be the case of a car Bluetooth system), or multiple computers that might share other components (networking, A2DP headsets) it's harder for it to continue to do the right thing without manual configuration steps. Those steps are pretty easy on a general purpose computer, but hard on a limited-interface device such as a headset.
I don't know how a shift to 802.xx would make that better, easier, harder or just different.
No, obscurity does help, but for a different reason. It reduces the overall impact of the opportunistic hackers. It's long, but here's the reason why:
1. No security system is perfect. 2. All security systems work by delaying the success of the attack long enough so the attacker gives up. 3. The internet is very, very big, and full of both attackers and targets. 4. A statistically significant number of people do as little as possible to accomplish a task. This includes time and effort spent securing systems. 5. From 4, that means many people accept default values when they don't matter. 6. Obscurity can be accomplished simply by changing default values to non-expected values (port numbers, version identification strings, etc.) 7. Many attackers are opportunistic, and will attack whatever systems they can identify that are easy to attack. 8. Opportunistic attackers use volume attack techniques. Zombie armies attacking default ports, or Google searches for known version identification strings or other artifacts that identify hackable systems, for example. 9. By hiding/obscuring any component, the opportunistic attackers may not identify or otherwise may skip attacking your system. 10. Systems change over time. What was secure yesterday may no longer be secure today. (Adding support for JavaScript to browsers created the possibility of cross-site scripting attacks, for example.) 11. Once an attack is recognized, a patch is generally created and updates made available. 12. If you were not attacked in the first wave of zombie attacks, you can possibly install the update before your system is recognized for what it is and compromised by someone.
So, by increasing only obscurity but not security, the amount of crap a victim has to deal with is cut by a large factor. It may delay being a member of the First Victim's Club long enough that you never become a victim. Sure, you do so at the expense of other systems on the internet, but they're not your responsibility, are they?
Opportunistic hackers represent a very large threat. Cleaning up behind them is very expensive. Changing a default value is cheap. By spending very little money, you dodge a very big bullet. Obscurity is indeed effective against opportunistic attackers.
But it is not effective against a targeted attacker. If someone wants to specifically violate your security for some reason, they are going to employ a different mode of attack. Non-standard defaults are meaningless, because you're not trying to hide -- they've already found you. Real security is still required.
For the most part I'm not worried about attackers because I can't worry about them. As you say, the attacker could bypass any test. Even on-line isn't a guarantee of assurance, as the attacker could be providing me with a false host that matches my false certs. There is no way to determine (or even prevent) compromise on a box I don't physically control. And cash registers aren't of any business value if they're locked up in a secure data center.
The reason I focus on the certs is mostly because I need them to work in the normal, non-attack scenario. I need a high level of confidence that the data I generate now will be readable later.
I certainly meant no offense with that first posting. It was not intended as an attack. I'm sorry it came across that way.
I don't think we're speaking on the topic in exactly the same way here.
I'm trying to solve the problem of "how do I know if this certificate (and signing CA root cert) on this cash register are good? How do I know they are not forgeries?" If I'm on-line, I can use the cert to authenticate a connection to a host, and assuming* I'm not also the victim of a simultaneous man-in-the-middle attack, I can trust that the cert is valid.
*Big assumption here.
But if I'm off-line, I simply have to trust the certs in my possession.
If I'm on-line and a customer gives me their credit card, I will use the cert, establish an authenticated connection to the authorizer, send the encrypted credit info, receive an approval, and send the customer off with his merchandise.
If I'm off-line, I'm taking my chances because I have to proceed without credit approval. Perhaps if it's just a one dollar bottle of soda, I'll accept the risk and approve it. But I still need to assure myself that I'll get paid by the customer's bank, and I also need to protect the customer's data. So I check the certificate I have on the local machine, walk its chain up to the root CA (which I also have on the local machine), and use the cert's key to encrypt the customer's credit info. I then have to store the encrypted data until such time that I'm back on-line and can send it forward. I may be too late to get the credit approved, but I still need to send the credit data to the customer's bank in order to get paid.
At this point it's still all about trust. I have to trust that the certs and key in my possession are not forgeries. If they are, I will have no way of recovering the credit info and getting paid. And if the attacker who replaced my valid certificates with forgeries is somewhere in the system harvesting the data, he alone will have the ability to decrypt the credit info, and use it for his evil purposes. As you said, there is nothing else that can be done at this point. An attacker who owns the system owns the whole system.
As I think we both agreed above, an HSM is about the most reliable way to protect a secret in this case. The best solution would be to perform all encryption in the HSM. That helps defend against the man-in-the-middle attack, again assuming the attacker can't tamper with or replace the HSM. But an HSM can be an expensive option when you're talking about many thousands of cash registers. A TPM chip can securely store enough data to verify a cert, though, and could be used to spot forgeries. (Again, assuming the attacker hasn't replaced the HSM or TPM drivers. An attacker with that level of access is certainly capable of any level of mischief. It always comes down to trusting the systems at some level or another.)
I'm pretty certain you don't know what you're talking about, and that's dangerous if you're advising others on security.
Don't be so quick to take offense if you don't understand the way someone else is going with a conversation. Take a moment to figure out what they mean before you descend into slander. You've been pretty hostile in this little conversation, and I've tried to be civil. Reciprocation would be appropriate.
The hardest part is ensuring the certificate signatures are valid. You have to ensure the encryption certs weren't replaced with evil certs, and that no rogue root certificate was installed on the POS system.
Huh? That's the whole point of a certificate. If it's replaced with an "evil" certificate it won't authenticate at the other end. You'd have to replace them at both ends.
You're assuming the certificate is used immediately to establish a connection. Point of sale terminals are not always on-line, and when they are off-line they must encrypt the authorization request and store it until it can be sent to the settlement system once they're back on-line. In that case, the terminal really needs to assure itself that the certificate is valid, because it might not be able to attempt the decryption until long after the customer has left with your merchandise and their charge card.
There's never a reason to have the private keys stored in the Point-Of-Sale application. The credit card data should be encrypted in the POS system using a public key borne on a verified certificate. It doesn't ever have to be decrypted at POS for any reason. Decryption should happen only at the point of authorization, and at the point of settlement with the bank. Those private keys are only in centrally located machines that can be much more easily secured than the thousands of cash registers located in thousands of stores.
The hardest part is ensuring the certificate signatures are valid. You have to ensure the encryption certs weren't replaced with evil certs, and that no rogue root certificate was installed on the POS system.
Now, if you are encrypting at a PIN Entry Device (PED), it's a bit different. PINs are most commonly encrypted using TDES, not public key cryptography. Because those devices actually store secret keys, they fall under the PCI PED guidelines. They store a master key used in a protocol called DUKPT (Derived Unique Key Per Transaction.) The device must pass various tests and analysis, and be physically hardened against an attacker attempting to retrieve the master key. The older ones I've examined used a combination of trip wires, sensor switches, epoxy, 10-layer PC boards, and soldering techniques (BGA packaging) to thwart the bad guys. I'm not saying they're impregnable, but they're physically pretty well secured.
Star Trek wasn't really about science, imo, so much as about society. Most episodes were about taking some modern social issue and turning it on its head to illustrate a point.
It had to be. New fictional science gadgets are interesting exactly once, but have no staying power without the social aspects. "Oh, look, a machine that predicts the future, but it requires three humans be genetically engineered to devote their lives to it forever." So now you've got a useful and creepy machine, but unless you explore what people do with it, how people deal with the tragedy of its creation, etc., it's a pretty boring story after the expose. Star Trek was a story of humanity, not of bits of technogadgetry.
Anybody remember the "glory pass" of the Enterprise at the start of the first Star Trek feature film? It's a perfect example of why Scalzi is full of it. They flew past the Enterprise in a shuttle taking several minutes to pan by the ship, pointing out each feature in grotesque detail. Someone like Scalzi would have been taking notes, counting rivet heads and portholes, measuring the frequency of the blinking lights, pondering if the blinking lights would be visible at warp speeds, etc. The rest of us thought the scene was boring as hell. "Yeah, it's the ship, how nice, now get to the interesting parts!"
Sure, we meant "show us more Persis Khambatta!" But that's social, right?
I was going to post a note here defending the sanity of the Star Trek fans, and claiming that at least the fans are not reading to each other from the Book of P'targh*, speaking in tongues, or believing that Kirk died saving the world.
Then I realized what I was writing.
* I made this word up because I thought it looked like Klingon. I'm sure a Klingon Grammar Nazi will attempt to leap through their monitor to kill me for some offense as a result. I look forward to seeing the CNN Headline news story tomorrow: "Nerd breaks nose in mother's basement attempting to leap through his monitor."
It's not just hospital workers (although that's what TFA is about.) Plenty of people are required to get a flu shot that you wouldn't expect need it.
The one that surprised me are local refinery workers. There is one refinery in our region that produces virtually all of the petroleum based fuel consumed locally. If the flu were to incapacitate 50% of the employees, the refinery would have to shut down. These are trained people needed to produce a critical product, and the refinery wouldn't have the time to train temps to take over for them. Pipelines don't exist to bring in refined products from elsewhere, and the rest of the nation's refining capacity would be strained to meet the demand.
Refinery workers are exposed to a lot of things you probably wouldn't want to be exposed to, but viruses aren't commonly among them. It'd probably be a great place to work if you wanted to avoid contact with other people.
Didn't we see Samba choke when enterprises tightening up security disabled ntlmv1?
Some changes are required, and will break things. The change from v1 to v2 was absolutely required. If Samba had implemented v2 perfectly, it wouldn't have broke. Perhaps with Microsoft's involvement, the protocols will not break with the next update.
My point is that it wasn't a breaking change, it was a change that revealed a flaw in Samba.
These people are in positions where they have to have access to the information to do their jobs. Locking them down so they can't get to the data without a partner would double labor costs (much more expensive than the 1-4% quoted in TFA.)
So the best answer is: give them the access they need, tell them you're logging it all, log it all, and *analyze the freakin' reports!* There are so many reports out there in most businesses that just get ignored. But we're talking about the early warning signs of theft, and they can't be ignored without consequences.
Record profits == capitalism in action. It's more American than apple pie.
I don't begrudge someone the right to make money, at least not when they play within the boundaries of the system. If 50,000 tone-deaf idiots want to give Britney Spears $100 each to hear her sing into an Auto-tune system for an hour, then Britney wins at capitalism.
Of course, Big Pharma is well known for not playing within the rules, and is certainly not above bribing 75% of Capitol Hill to get their way. But the answer there is to bring them back in line with the rules, not to change the process so they can't make "record profits."
If software shouldn't be patentable - which is a different question than "is software patentable" - then Congress is the one that should amend 35 USC 101 to exclude software, not the Supreme Court. Otherwise, they're merely being activist judges.
First, the phrase "activist judges" was created as a political hot-button codeword to try to sway people emotionally instead of rationally. It's a ploy to discredit the work of the legal system using fear and anger instead of logic and reason. It has no place in a legal debate.
And in the case of patents, your argument is not correct. 35 USC 146 clearly states that the U.S. Court of Appeals for the Federal Circuit is to make the decision in case of a disagreement with a ruling of the Board of Patent Appeals. Congress explicitly granted the courts (whether they be "activists" or not) the power to decide these cases. And Bilski is one such case.
Because our legal system is based on precedent, not just on written law, a case such as Bilski can have a ripple effect on other similar decisions. Sometimes I'd rather have a system like the Swiss courts, where each case is tried on its own merits and judged only against the law, not against how the courts ruled on your neighbor's case. But we have what we have.
35 USC 101 is very simple, and says on its face: "subject to the conditions and requirements of this title." That means that it's not simply "processes are patentable", but you have to go through the entire document to make that determination. Reading further, in MPEP 2106.01, you can see some of those requirements that are relevant:
"Since a computer program is merely a set of instructions capable of being executed by a computer, the computer program itself is not a process and USPTO personnel should treat a claim for a computer program, without the computer-readable medium needed to realize the computer program's functionality, as nonstatutory functional descriptive material. When a computer program is claimed in a process where the computer is executing the computer program's instructions, USPTO personnel should treat the claim as a process claim. ** When a computer program is recited in conjunction with a physical structure, such as a computer memory, USPTO personnel should treat the claim as a product claim. **"
They specifically state here that a program is nonstatutory (not patentable) unless the program is supporting a patentable process. In the case of Bilski, the program is supporting their process. The real question is still if Bilski's business method patent is valid.
Bilski is an abstract business method patent, and that's exactly why it's been thrown out by the court of appeals. Yes, they patented software to do the computations, but in the end it's a process more than just software.
(Their process is that of selling a lot of people "fixed cost" subscriptions to a service that can have a variable cost, such as heating fuel in the winter, and then using the leverage of that large group of people to drive down the sellers' bids on the fuel, and making a profit on the difference.)
We're all expecting/hoping that if Bilski is thrown out because it doesn't meet the "tangible transformation of a thing" test that the software component will also be thrown out for the same reason.
Software patents in general kind of just happened by accident. If I recall correctly the first software patent was for a chemical process that used a computer to operate valves to moderate the reaction, and from there the lawyers have just ignored the chemistry part and decided "software is patentable." It's never been challenged like this before, so we're all crossing our fingers and hoping they die and stay dead.
The patent system was established with the intent to create temporary monopolies for inventors in order to encourage the development and dissemination of that R&D throughout society. The problem is that too often, it's used to destroy competitors.
OK, let's look at one of the industries most reviled for price gouging in America: pharmaceuticals. They claim to spend anywhere from $100 million to a billion dollars or more to come up with a successful new drug. They patent it. Then, with the required years of development and testing, they get to put it on the market for maybe 12 years or so, without competition, and they charge anywhere from $100/month to $1000/month or more. After 12 years, GenericCo starts selling them for $4/month, so they then have to drop their prices to compete.
For the moment, let's ignore all the criminal and other misdeeds of big pharma (phony studies "proving" generics are bad, misleading marketing to doctors and politicians including golf trips to St. Andrews, selling pointless medicines for not-serious conditions such as "restless leg", "weak boners", etc.,) and focus on just the patent portion of this.
If it took them $500 million dollars to create the drug, and they have only 12 years to sell it, they have to make more than $500 million dollars to make the investment worthwhile. Don't forget, for each useful drug they invent, they also invest millions on drugs that don't work, or drugs that are eventually shown to have toxic side effects and must be pulled from the market. And just about every death that occurs while a patient is taking their drug ends up with a lawsuit that must be defended against.
Without that 12 year period of patent protection, generic drug companies could usually start making cheaper products almost immediately. There would be no reason for pharmaceutical firms to continue to pump a billion dollars into any drug if it's never going to see its return on investment, so innovation would end. The search for a cure for cancer, or of the many chronic conditions such as lupus, muscular dystrophy, etc., would end because there's no profit to be made even if they succeed.
That's the general argument in favor of patents. As a society, we pay the creative and smart people to keep being creative and smart. Do I want them to stop innovating, and not create the cure for whatever disease I'll come down with in 3-5 years? I certainly hope not!
The question here is: does this imply the same for software patents? Not even close. The bar to entering the software market is non-existent. Anyone with a computer and internet connection can download a professional quality operating system and developer studio for free, take online courses in everything from programming and calculus to software engineering, and start innovating almost immediately. It costs them almost nothing to produce and deliver their products, and they have limited to no liability to the users of them. In contrast to the hundreds of pharmaceutical firms, there are millions of developers. Innovation is going to happen continually with or without patents. And innovation is global: what is created in Shanghai can be downloaded in Chicago in seconds.
Even if Bilski is kind of an "end run" around the general issue of patents on software being a bad idea, they should still be prohibited before they make the United States a pariah of developed software.
Slashdot Mirror
Sorry, yes, I meant watt-hours, not kilowatt-hours. It was a think-o. I did the calculations several years ago, and I didn't bother to go look them up again when I posted this morning. It's probably time to redo them anyway, as CPUs are now much more energy efficient than they were back then.
The point is that the amount of fuel being burned to re-confirm a statistical theory was staggering. We knew it would take roughly X tests to crack a DES key, and it did. Proving it once was exciting. We knew it would take Y tests to crack an RC4-56 key, and it did. Proving that was somewhat less exciting. There was no point in burning up further fuel just to prove that we could crack an RC5-64 key in Z tests. Fine, we know it'll work, save the damn fuel.
The last time I measured the difference between an Athlon 2400 CPU sitting idle at a Windows explorer desktop (somewhere around 3% CPU usage) and the same CPU with its load peg at 100%, the difference was 60 Watts extra.
The reason I went looking was because I had installed distributed.net's cracker on one day, and the next when I went into the room I noticed that it was uncomfortably warmer than the previous day. So I used my battery backup's internal statistics to measure current draw, and I was very surprised to see the delta. I've since confirmed similar behavior with my latest desktop using a Kill-A-Watt, but I don't remember the exact numbers for load vs. idle.
Nothing is an absolute in cryptography. You still have to make guesses as to when you hit upon the correct answer. And an adversary has every incentive to not make it easy for you.
But the adversary might be lazy, and let the tools do their jobs by default. When they decrypt their archive, they probably want to immediately use the results without going through a second deobfuscation step. Never discount the value of human nature and laziness -- they could save you tons of work.
As a cryptanalyst, you have to look for shortcuts. If I were given foo.7z and was told it was encrypted, I'd only have a few formats to try. It could be a bare 7z format (described here, or a compressed version. I'd have to figure out what possible artifacts I could look for in the decrypted file. But knowing it's in 7z format makes the job easier. (Of course, 7zip's key strengthening routine would not make it easier, as the key is encrypted 2^18 times!)
I'm not saying it's easy. There are thousands of file formats in common use out there. And I'd have only hope that the adversary is using one of them. But it's really not much different of a problem than "magic" already solves. And I could probably leverage a .magic file to help with the identification task.
A "known plaintext attack" is a specific cryptographic technique where you use known plaintext material to help break the key. A very simple example might be a Caesar cypher where you know the word ROME is in the message. You could then try subtracting the values of ROME against the letters in the message BUUBD LSPNF, and you'd quickly find the last four letters where the differences are all -1,-1,-1,-1, thus the key is to shift each letter by one, yielding the message ATTACK ROME. Without the plaintext you'd have to solve the cypher the old fashioned way.
The ULTRA project who decrypted Enigma didn't use a known plaintext attack either. They couldn't reverse engineer the keys from the cribs they obtained. Instead, they used the cribs to solve a different problem (which happens to be the same problem I'm describing.) They had to put in "stop words" to get the bombes to mechanically stop spinning when they encountered a possible solution.
What I described is not a known plaintext attack. It is simply testing the output of the algorithm against possible solutions. No algorithm is hardened against this because this is the normal function of the cypher.
It wasn't carbon, but the fuel consumed that was my first thought. Back when distributed.net was busy burning energy to win these pointless challenges, I did some rough calculations on the electricity required to solve it.
Turns out that the energy spent breaking RC5-64 used somewhere between 2 and 50 *trains* full of coal.
And that was only the energy directly consumed by the computers involved, and not any of the heating or cooling costs associated with it. And sure, more modern CPUs are more energy efficient, and I extrapolated the figures from a lot of published sources and made a lot of assumptions. But regardless of CO2 or greenhouse gasses or dirty coal or any of that environmental stuff, that's a lot of irreplaceable fossil fuel that's now gone.
I don't think it's sad or tainted to consider the overall impact of what you do. Saying "oh, I want to help search for E.T." is one thing. It may cost you an extra 1440 kWh/day, but you have the money, no big deal. But understanding that SETI@HOME is causing tens of thousands of people around the globe to collectively burn tons of fuel every day might make some of the volunteers rethink their decision. Ignoring that is the kind of perspective that thoughtlessly sucks up our finite resources.
And no, I don't consider alien hunting a valuable use of energy, at least not at this time in our history. Once we have fusion reactors or some other form of "free energy", all that will change.
Go ahead and crack keys, search for Extra Terrestrials, or fold proteins, or whatever you want to do with your box. Leave your lights on 24x7. Run the furnace and the air conditioner together. Just understand that what you do today has an impact, and consider the value of the outcome.
That's only a problem if you have no idea what the encrypted data might be. But in most reality-based cases, that's not the problem. You almost always have the clues you need.
In this case, for example, the file is a ZIP archive. That means the archive contains in the clear the original file names including any extensions, such as .jpeg, .bmp, .doc, .pdf, or whatever. All those file types have artifacts you can test for. They all have specific formats. They'll have version numbers, dimensions that must fall within reasonable boundaries, or other attributes that simply won't produce a coherent file unless they're correct.
For example, a JPEG image file is a container and is filled with markers identifying all the different sections. They all must be right or it won't display. So you'd start by looking for the SOI marker as the first byte of the file (0xffd8) or you'd throw it out. After the SOI you'd have to find another valid JPEG marker (two more bytes beginning with 0xFF.) So that's three bytes you'd have to match exactly, and the fourth byte would have to be on the list of valid markers. After you find the next marker, it'll probably be followed by a length (two or four more bytes). If that length is greater than your file size, it's a fail. Sure, if all that passes you'd have to decrypt more data to figure out if you're still in a valid file, but the chances are now only about 1 in 16 million keys tested. You then farm all these "potentials" to a machine or other process dedicated to deeper examination of the candidates.
If I were writing this, I'd have enough smarts in the key tester to look for all possibilities within the first blocksize of the cypher. Anything that looked reasonable at that point would be exported to the "evaluate potentials" system.
Every data file has its structure. You just have to look for it.
What, you don't know how to set the clock on your computer back to June 1st, then fire up Word and type up the document? That amount of effort certainly doesn't take a techie or a fancy bit editor. It only takes a few drops of imagination. It's certainly within the skillset of your average cop.
The only requirement is that you set the clock back before creating the new doc. It won't work to set the clock back and try to edit it after the doc has been created. But in that case you'd just have to create another new doc and retype in the old text. It's no big deal, but when people are stressed out enough that they're forging "evidence" they're also likely in a rush, and may make a careless mistake.
I'm not from Virginia, you insensitive Claud!
Sure, that makes sense.
But the complexity could be managed, or even used. Perhaps with a more capable set of devices I could create "context aware profiles." When I'm home, maybe I want the phone functions to ring the house cordless extensions for my family phone list and the phone's audio stream to go to the stereo, unless the TV is on. It might be difficult or complex to set up, but I could do the configuration on a browser through some clever UI, and tell it to store my wi-fi profile rules on the "me" device (probably my phone), which would share them with all the rest of my devices on demand. The phone would then follow the rules to figure out which profile applies in which scenarios.
That'd be really cool. If the GPS device says "at work", the profile would be silent ringing. If the calendar event category is "important", it would send the callers to voicemail. And I would carry all that stuff automatically with the phone.
While I really like the profiles and the interoperability, the more devices that you get in your "circle of stuff" the harder it is to have all your devices continue to default to doing the "right thing".
With one phone, one headset, one computer, one handheld, it's pretty simple. With multiple phones sharing a single hands-free provider (as might be the case of a car Bluetooth system), or multiple computers that might share other components (networking, A2DP headsets) it's harder for it to continue to do the right thing without manual configuration steps. Those steps are pretty easy on a general purpose computer, but hard on a limited-interface device such as a headset.
I don't know how a shift to 802.xx would make that better, easier, harder or just different.
No, obscurity does help, but for a different reason. It reduces the overall impact of the opportunistic hackers. It's long, but here's the reason why:
1. No security system is perfect.
2. All security systems work by delaying the success of the attack long enough so the attacker gives up.
3. The internet is very, very big, and full of both attackers and targets.
4. A statistically significant number of people do as little as possible to accomplish a task. This includes time and effort spent securing systems.
5. From 4, that means many people accept default values when they don't matter.
6. Obscurity can be accomplished simply by changing default values to non-expected values (port numbers, version identification strings, etc.)
7. Many attackers are opportunistic, and will attack whatever systems they can identify that are easy to attack.
8. Opportunistic attackers use volume attack techniques. Zombie armies attacking default ports, or Google searches for known version identification strings or other artifacts that identify hackable systems, for example.
9. By hiding/obscuring any component, the opportunistic attackers may not identify or otherwise may skip attacking your system.
10. Systems change over time. What was secure yesterday may no longer be secure today. (Adding support for JavaScript to browsers created the possibility of cross-site scripting attacks, for example.)
11. Once an attack is recognized, a patch is generally created and updates made available.
12. If you were not attacked in the first wave of zombie attacks, you can possibly install the update before your system is recognized for what it is and compromised by someone.
So, by increasing only obscurity but not security, the amount of crap a victim has to deal with is cut by a large factor. It may delay being a member of the First Victim's Club long enough that you never become a victim. Sure, you do so at the expense of other systems on the internet, but they're not your responsibility, are they?
Opportunistic hackers represent a very large threat. Cleaning up behind them is very expensive. Changing a default value is cheap. By spending very little money, you dodge a very big bullet. Obscurity is indeed effective against opportunistic attackers.
But it is not effective against a targeted attacker. If someone wants to specifically violate your security for some reason, they are going to employ a different mode of attack. Non-standard defaults are meaningless, because you're not trying to hide -- they've already found you. Real security is still required.
For the most part I'm not worried about attackers because I can't worry about them. As you say, the attacker could bypass any test. Even on-line isn't a guarantee of assurance, as the attacker could be providing me with a false host that matches my false certs. There is no way to determine (or even prevent) compromise on a box I don't physically control. And cash registers aren't of any business value if they're locked up in a secure data center.
The reason I focus on the certs is mostly because I need them to work in the normal, non-attack scenario. I need a high level of confidence that the data I generate now will be readable later.
I certainly meant no offense with that first posting. It was not intended as an attack. I'm sorry it came across that way.
I don't think we're speaking on the topic in exactly the same way here.
I'm trying to solve the problem of "how do I know if this certificate (and signing CA root cert) on this cash register are good? How do I know they are not forgeries?" If I'm on-line, I can use the cert to authenticate a connection to a host, and assuming* I'm not also the victim of a simultaneous man-in-the-middle attack, I can trust that the cert is valid.
*Big assumption here.
But if I'm off-line, I simply have to trust the certs in my possession.
If I'm on-line and a customer gives me their credit card, I will use the cert, establish an authenticated connection to the authorizer, send the encrypted credit info, receive an approval, and send the customer off with his merchandise.
If I'm off-line, I'm taking my chances because I have to proceed without credit approval. Perhaps if it's just a one dollar bottle of soda, I'll accept the risk and approve it. But I still need to assure myself that I'll get paid by the customer's bank, and I also need to protect the customer's data. So I check the certificate I have on the local machine, walk its chain up to the root CA (which I also have on the local machine), and use the cert's key to encrypt the customer's credit info. I then have to store the encrypted data until such time that I'm back on-line and can send it forward. I may be too late to get the credit approved, but I still need to send the credit data to the customer's bank in order to get paid.
At this point it's still all about trust. I have to trust that the certs and key in my possession are not forgeries. If they are, I will have no way of recovering the credit info and getting paid. And if the attacker who replaced my valid certificates with forgeries is somewhere in the system harvesting the data, he alone will have the ability to decrypt the credit info, and use it for his evil purposes. As you said, there is nothing else that can be done at this point. An attacker who owns the system owns the whole system.
As I think we both agreed above, an HSM is about the most reliable way to protect a secret in this case. The best solution would be to perform all encryption in the HSM. That helps defend against the man-in-the-middle attack, again assuming the attacker can't tamper with or replace the HSM. But an HSM can be an expensive option when you're talking about many thousands of cash registers. A TPM chip can securely store enough data to verify a cert, though, and could be used to spot forgeries. (Again, assuming the attacker hasn't replaced the HSM or TPM drivers. An attacker with that level of access is certainly capable of any level of mischief. It always comes down to trusting the systems at some level or another.)
Don't be so quick to take offense if you don't understand the way someone else is going with a conversation. Take a moment to figure out what they mean before you descend into slander. You've been pretty hostile in this little conversation, and I've tried to be civil. Reciprocation would be appropriate.
The hardest part is ensuring the certificate signatures are valid. You have to ensure the encryption certs weren't replaced with evil certs, and that no rogue root certificate was installed on the POS system.
Huh? That's the whole point of a certificate. If it's replaced with an "evil" certificate it won't authenticate at the other end. You'd have to replace them at both ends.
You're assuming the certificate is used immediately to establish a connection. Point of sale terminals are not always on-line, and when they are off-line they must encrypt the authorization request and store it until it can be sent to the settlement system once they're back on-line. In that case, the terminal really needs to assure itself that the certificate is valid, because it might not be able to attempt the decryption until long after the customer has left with your merchandise and their charge card.
There's never a reason to have the private keys stored in the Point-Of-Sale application. The credit card data should be encrypted in the POS system using a public key borne on a verified certificate. It doesn't ever have to be decrypted at POS for any reason. Decryption should happen only at the point of authorization, and at the point of settlement with the bank. Those private keys are only in centrally located machines that can be much more easily secured than the thousands of cash registers located in thousands of stores.
The hardest part is ensuring the certificate signatures are valid. You have to ensure the encryption certs weren't replaced with evil certs, and that no rogue root certificate was installed on the POS system.
Now, if you are encrypting at a PIN Entry Device (PED), it's a bit different. PINs are most commonly encrypted using TDES, not public key cryptography. Because those devices actually store secret keys, they fall under the PCI PED guidelines. They store a master key used in a protocol called DUKPT (Derived Unique Key Per Transaction.) The device must pass various tests and analysis, and be physically hardened against an attacker attempting to retrieve the master key. The older ones I've examined used a combination of trip wires, sensor switches, epoxy, 10-layer PC boards, and soldering techniques (BGA packaging) to thwart the bad guys. I'm not saying they're impregnable, but they're physically pretty well secured.
Star Trek wasn't really about science, imo, so much as about society. Most episodes were about taking some modern social issue and turning it on its head to illustrate a point.
It had to be. New fictional science gadgets are interesting exactly once, but have no staying power without the social aspects. "Oh, look, a machine that predicts the future, but it requires three humans be genetically engineered to devote their lives to it forever." So now you've got a useful and creepy machine, but unless you explore what people do with it, how people deal with the tragedy of its creation, etc., it's a pretty boring story after the expose. Star Trek was a story of humanity, not of bits of technogadgetry.
Anybody remember the "glory pass" of the Enterprise at the start of the first Star Trek feature film? It's a perfect example of why Scalzi is full of it. They flew past the Enterprise in a shuttle taking several minutes to pan by the ship, pointing out each feature in grotesque detail. Someone like Scalzi would have been taking notes, counting rivet heads and portholes, measuring the frequency of the blinking lights, pondering if the blinking lights would be visible at warp speeds, etc. The rest of us thought the scene was boring as hell. "Yeah, it's the ship, how nice, now get to the interesting parts!"
Sure, we meant "show us more Persis Khambatta!" But that's social, right?
bat'leth
Sproing!
And the nerd trap works! I knew *someone* was going to quote some Klingon word in response to all the slander.
For your troubles, I'll punch an extra hole in your geek card. I'm sure it'll heal your wounds quicker that way.
I was going to post a note here defending the sanity of the Star Trek fans, and claiming that at least the fans are not reading to each other from the Book of P'targh*, speaking in tongues, or believing that Kirk died saving the world.
Then I realized what I was writing.
* I made this word up because I thought it looked like Klingon. I'm sure a Klingon Grammar Nazi will attempt to leap through their monitor to kill me for some offense as a result. I look forward to seeing the CNN Headline news story tomorrow: "Nerd breaks nose in mother's basement attempting to leap through his monitor."
It's not just hospital workers (although that's what TFA is about.) Plenty of people are required to get a flu shot that you wouldn't expect need it.
The one that surprised me are local refinery workers. There is one refinery in our region that produces virtually all of the petroleum based fuel consumed locally. If the flu were to incapacitate 50% of the employees, the refinery would have to shut down. These are trained people needed to produce a critical product, and the refinery wouldn't have the time to train temps to take over for them. Pipelines don't exist to bring in refined products from elsewhere, and the rest of the nation's refining capacity would be strained to meet the demand.
Refinery workers are exposed to a lot of things you probably wouldn't want to be exposed to, but viruses aren't commonly among them. It'd probably be a great place to work if you wanted to avoid contact with other people.
Didn't we see Samba choke when enterprises tightening up security disabled ntlmv1?
Some changes are required, and will break things. The change from v1 to v2 was absolutely required. If Samba had implemented v2 perfectly, it wouldn't have broke. Perhaps with Microsoft's involvement, the protocols will not break with the next update.
My point is that it wasn't a breaking change, it was a change that revealed a flaw in Samba.
"Trust, but verify."
These people are in positions where they have to have access to the information to do their jobs. Locking them down so they can't get to the data without a partner would double labor costs (much more expensive than the 1-4% quoted in TFA.)
So the best answer is: give them the access they need, tell them you're logging it all, log it all, and *analyze the freakin' reports!* There are so many reports out there in most businesses that just get ignored. But we're talking about the early warning signs of theft, and they can't be ignored without consequences.
Record profits == capitalism in action. It's more American than apple pie.
I don't begrudge someone the right to make money, at least not when they play within the boundaries of the system. If 50,000 tone-deaf idiots want to give Britney Spears $100 each to hear her sing into an Auto-tune system for an hour, then Britney wins at capitalism.
Of course, Big Pharma is well known for not playing within the rules, and is certainly not above bribing 75% of Capitol Hill to get their way. But the answer there is to bring them back in line with the rules, not to change the process so they can't make "record profits."
If software shouldn't be patentable - which is a different question than "is software patentable" - then Congress is the one that should amend 35 USC 101 to exclude software, not the Supreme Court. Otherwise, they're merely being activist judges.
First, the phrase "activist judges" was created as a political hot-button codeword to try to sway people emotionally instead of rationally. It's a ploy to discredit the work of the legal system using fear and anger instead of logic and reason. It has no place in a legal debate.
And in the case of patents, your argument is not correct. 35 USC 146 clearly states that the U.S. Court of Appeals for the Federal Circuit is to make the decision in case of a disagreement with a ruling of the Board of Patent Appeals. Congress explicitly granted the courts (whether they be "activists" or not) the power to decide these cases. And Bilski is one such case.
Because our legal system is based on precedent, not just on written law, a case such as Bilski can have a ripple effect on other similar decisions. Sometimes I'd rather have a system like the Swiss courts, where each case is tried on its own merits and judged only against the law, not against how the courts ruled on your neighbor's case. But we have what we have.
35 USC 101 is very simple, and says on its face: "subject to the conditions and requirements of this title." That means that it's not simply "processes are patentable", but you have to go through the entire document to make that determination. Reading further, in MPEP 2106.01, you can see some of those requirements that are relevant:
They specifically state here that a program is nonstatutory (not patentable) unless the program is supporting a patentable process. In the case of Bilski, the program is supporting their process. The real question is still if Bilski's business method patent is valid.
Bilski is an abstract business method patent, and that's exactly why it's been thrown out by the court of appeals. Yes, they patented software to do the computations, but in the end it's a process more than just software.
(Their process is that of selling a lot of people "fixed cost" subscriptions to a service that can have a variable cost, such as heating fuel in the winter, and then using the leverage of that large group of people to drive down the sellers' bids on the fuel, and making a profit on the difference.)
We're all expecting/hoping that if Bilski is thrown out because it doesn't meet the "tangible transformation of a thing" test that the software component will also be thrown out for the same reason.
Software patents in general kind of just happened by accident. If I recall correctly the first software patent was for a chemical process that used a computer to operate valves to moderate the reaction, and from there the lawyers have just ignored the chemistry part and decided "software is patentable." It's never been challenged like this before, so we're all crossing our fingers and hoping they die and stay dead.
The patent system was established with the intent to create temporary monopolies for inventors in order to encourage the development and dissemination of that R&D throughout society. The problem is that too often, it's used to destroy competitors.
OK, let's look at one of the industries most reviled for price gouging in America: pharmaceuticals. They claim to spend anywhere from $100 million to a billion dollars or more to come up with a successful new drug. They patent it. Then, with the required years of development and testing, they get to put it on the market for maybe 12 years or so, without competition, and they charge anywhere from $100/month to $1000/month or more. After 12 years, GenericCo starts selling them for $4/month, so they then have to drop their prices to compete.
For the moment, let's ignore all the criminal and other misdeeds of big pharma (phony studies "proving" generics are bad, misleading marketing to doctors and politicians including golf trips to St. Andrews, selling pointless medicines for not-serious conditions such as "restless leg", "weak boners", etc.,) and focus on just the patent portion of this.
If it took them $500 million dollars to create the drug, and they have only 12 years to sell it, they have to make more than $500 million dollars to make the investment worthwhile. Don't forget, for each useful drug they invent, they also invest millions on drugs that don't work, or drugs that are eventually shown to have toxic side effects and must be pulled from the market. And just about every death that occurs while a patient is taking their drug ends up with a lawsuit that must be defended against.
Without that 12 year period of patent protection, generic drug companies could usually start making cheaper products almost immediately. There would be no reason for pharmaceutical firms to continue to pump a billion dollars into any drug if it's never going to see its return on investment, so innovation would end. The search for a cure for cancer, or of the many chronic conditions such as lupus, muscular dystrophy, etc., would end because there's no profit to be made even if they succeed.
That's the general argument in favor of patents. As a society, we pay the creative and smart people to keep being creative and smart. Do I want them to stop innovating, and not create the cure for whatever disease I'll come down with in 3-5 years? I certainly hope not!
The question here is: does this imply the same for software patents? Not even close. The bar to entering the software market is non-existent. Anyone with a computer and internet connection can download a professional quality operating system and developer studio for free, take online courses in everything from programming and calculus to software engineering, and start innovating almost immediately. It costs them almost nothing to produce and deliver their products, and they have limited to no liability to the users of them. In contrast to the hundreds of pharmaceutical firms, there are millions of developers. Innovation is going to happen continually with or without patents. And innovation is global: what is created in Shanghai can be downloaded in Chicago in seconds.
Even if Bilski is kind of an "end run" around the general issue of patents on software being a bad idea, they should still be prohibited before they make the United States a pariah of developed software.