Superconductor

Cryptol

Cryptographic algorithms are typically very complicated, which means that it's hard to get them working correctly in either hardware or software. If you're implementing a new one, you often need to carefully step through your algorithm by hand to make sure that it's correct, a process that can be very time consuming.

To make this easier, a company called Galois has made Cryptol, a domain-specific language that's designed for the sole purpose of specifying cryptographic algorithms. From looking at the Cryptol Programming Guide, it looks like Cryptol is realy designed for specifying symmetric algoritms and hash functions instead of public-key algorithms. Once you develop and debug your algorithm in Cryptol, you can then create an implementation of your algorithm in C, VHDL or Haskell. From Example 8-1 in the Cryptol Programming Guide, here's what the high-level structure of DES looks like in Cryptol:

des : {a b} (a > = 7) = > ([2**(a- 1)],[b][48]) - > [64];
des (pt, keys) = permute (FP, swap (split last))
where { pt’ = permute (IP, pt);
   iv = [| round (k, split lr)
   | | k < - keys
   | | lr < - [pt’] # iv
   | ];
   last = iv @ (width keys - 1);
};
round (k, [l r]) = r # (l ^ f (r, k));
f (r, k) = permute(PP, SBox(k ^ permute(EP, r)));
swap [a b] = b # a;
permute : {a b} (b > = 1) = > ([a][b], [2**(b - 1)]) - > [a];
permute (p, m) = [| m @ (i - 1) | | i < - p | ];

Cryptol also provides a way to check an implementation of an algorithm against a reference specification that's written in Cryptol. That may be the best use of Cryptol; it's certainly more useful that the ability to implement your algorithm in Haskell. This means that organizations like the IEEE Security in Storage Working Group that are defining new modes of operation of AES can provide a reference specification in Cryptol and anyone implementing the new modes can use Cryptol to verify that their implementation is correct. That's a handy capability to have.

2008 Dubious Data Awards

Information security is a field in which it's often frustratingly difficult to get accurate and useful data. Much of the data that is widely quoted isn't actually accurate. We've mentioned this before when we talked about the misperceptions around the insider threat and the cost of managing passwords. And even if you have accurate data, the fact that technology changes rapidly means that the field of information security also changes rapidly as new vulnerabilities are discovered and old ones patched.

It looks like having statistics that aren't quite accurate isn't limited to just information security. There are enough cases of the improper or misleading use of statistics to justify a group of researchers forming STATS, a non-profit, non-partisan research organization affiliated with George Mason University. The mission of STATS is to point out the common misuse and abuse of statistics. The STATS web site has both quick summaries that describe cases where statistics aren't used quite as accurately as they could be as well as longer case studies. Both are interesting reading.

STATS just released the 2008 installment of their Dubious Data Awards. None of this year's awards seem to relate to information security, but they're still interesting to read about. We should certainly be skeptical of any data that's used to support either the sale of a product or a public policy decision. In both of these cases, there's little incentive to present a balanced, unbiased view of what's really what.

Scrum seems to work

I once worked for a security product company that had serious management and organizational issues. This wasn't obvious at first, but it quickly became painfully clear. The point when I realized that there was absolutely no hope for this company was when I was told that people in marketing weren't allowed to talk to people in engineering. Instead, all communications between the two departments had to be through formal meetings. That's right - all of them.

Because the product management function was part marketing and the project management function was part of engineering, this meant that there was a huge obstacle to any communications at all. The project manager, who had done this sort of stuff for many years, assured me that this was the right way to do things. I believed that he was wrong back then and I still believe that he was wrong today. In retrospect, this was one of the worst ideas that I've ever seen. If you feel the need to ban all direct communications between marketing and engineering, you're probably doomed to failure. If you get to that point, why bother actually spend your time on making and selling products? It's only a matter of time until your organization fails, and you might as well as get a head start by updating your resume before you really need to.

At Voltage, we use an iterative and incremental process called Scrum. Scrum is somewhat trendy. Scrum isn't perfect, but it seems to have allowed us to get more useful features into our products more quickly than our previous software engineering processes allowed. It's certainly worked for us. It probably makes some people very uncomfortable - the type of people who insist that all discussions between marketing and engineering take place in formal meetings. But even if that's all that it can accomplish, it's probably worth looking at.

A Different Philosophy on Preventing Drunk Drivers

Suppose someone gets caught drinking and driving. They often avoid jail time, but in some cases the courts mandate a breathalyzer be installed in the car, it won't start unless the driver passes the sobriety test. In other cases, the offender's driver's license is revoked. The message is, "If you drink, don't drive."

I think that's wrong. I think if people are caught drinking and driving, they should not lose their license to drive, they should lose their license to drink.

In my opinion, here's how the system should work. Your drivers license, by default, has a red stripe through it, meaning you aren't allowed to buy liquor. If you want the red stripe to go away, prove to the DMV you are of legal age (which should be 18, not 21, in my opinion) and you have no drunk driving convictions.

If you have no drivers license, but would like to buy liquor, get a license to drink (an ID card like the drivers license).

We now punish liquor stores and bars if they sell and/or serve alcohol to underage people, we would simply update that to punish them for serving to people who have no license to drink. Laws now say that citizens can be held liable if they serve alcohol to underage people (even if they don't sell it), we would update that as well.

Of course, this would not prevent people who lost their license to drink from obtaining alcohol, but I think it would make it harder for them to get it, and harder to get it away from their homes. That is, if someone gets a few beers from the fridge or a few shots from the liquor cabinet at home, we can't stop them. But they are less likely to drive after that. People who drink and drive are often going home after drinking.

Certainly this would not prevent all drinking and driving, but the current system doesn't either. We have an imperfect system, now, so if we replace it with another imperfect system that does a better job of reducing the problem, then we're still coming out ahead.

Another advantage of this system is that bars, restaurants, nightclubs, liquor stores, and beer, wine, and liquor producers will all have a monetary interest in reducing drinking and driving. They would spend some money and effort themselves to reduce the problem. That means some of the costs of fixing the problem will be borne by those who help create it.

One disadvantage is that it might make everyone a law enforcer. If you have a party at your house and serve alcohol, do you have to check everyone's ID? We would have to address this issue. Maybe we do say people who host parties are responsible for keeping alcohol oout of the hands of non-licensed drinkers. Or maybe there is a less draconian solution.

Another reason I like this idea is that it does not restrict someone's ability to make a living. Driving to and from work can sometimes be a necessity to hold a job (no public transportation available, cabs would be too expensive, carpooling not possible), so taking away a drivers license can make it too difficult to hold a job. We don't want drunk drivers to not work, we want them to quit drinking and driving.

If we want to prevent the drinking and driving combination, take away one of those elements. Why not take away the drinking rather than the driving?

Why PKI is still used

It's always fun to watch babies. They're born knowing absolutely nothing and have to learn how the world around them by watching how things work. Once they get a bit older, they seem to start doing experiments to check if what they think is actually true. When they're very young, for example, they notice that everything falls when it's dropped. When they get a bit older they'll try dropping things again and again to see if things really do fall every time they're dropped. After a while, they seem to decide that they've tested their hypothesis enough times and they stop dropping things. This is why adults don't do some of the things that babies do. Adults typically don't drop things just to see if they'll fall because they already did it hundreds of times when they were babies.

When they're learning about how the world around them works, babies will eventually give up if they find something doesn't work. They just file that away as part of their understanding of the world. On the other hand, adults also seem unwilling to learn from experience the same way that babies do. Some even insist on moving forward with technologies that have always failed in the past. It's enough to remind you of the following exchange in The Princess Bride:

Wesley: "Aha! Your pig fiancé is too late! A few more steps and we'll be safe in the fire-swamp."

Buttercup: "We'll never survive."

Wesley: "Nonsense! You're only saying that because no one ever has."

Some people seem to believe that they'll be able to succeed with difficult technologies, even though most others fail. PKI is probably a good example of this. PKI has been around for quite a while. The digital certificate was invented over 30 years ago and the first version of the X.509 standard that defines how to use certificates was completed over 20 years ago. But except for the single notable use in SSL, the technology has essentially gone nowhere in the past few decades. The root of the problem is essentially that while machines don't mind using digital certificates, people hate them.

Despite this clear evidence of failure, some organizations have still not noticed the trend in which trying to have people use digital certificates has a very high chance of failure. Maybe they see themselves as Wesley in The Princess Bride, who does indeed manage to survive the Fire Swamp despite the failure of those that come before him. On the other hand, Wesley had one thing going for him that most corporate IT departments don't: the fact that the scriptwriter was on his side. Consultants can help with many difficult issues, but even the best consultants don't have that level of influence.

The play's the thing

The play's the thing

Wherein I'll catch the conscience of the King.

-William Shakespeare, Hamlet II, 2, 599

One of the conventions that has been around ever since classical Greek drama is the three-act structure. In the first act you introduce the characters; in the second act you get them in trouble; in the third act you get them out of the trouble. You might summarize this as boy meets girl, boy loses girl, boy gets girl back again. All three acts aren't necessarily the same length. It's common for the second act to be much longer than the third act, for example.

It's a very common pattern. You can see it, for example, in the first three Star Wars movies as they tell the story of the redemption of Anakin Skywalker. In Star Wars (the first act) we meet the main characters. In The Empire Strikes Back (the second act), things don't look good for Anakin. He ends up cutting his son’s hand off and it looks like he’ll be on the side of evil forever. In The Return of the Jedi (the third act), however, he finally overcomes the forces of evil and returns to the side of good.

The three-act structure might even provide a framework for thinking about many information technologies. Let's try to see how well the history of the Internet fits into this structure.

The first act of this play is probably the introduction of the Internet and its adoption by businesses for communications. At that point we know all of the players. The Internet certainly has a role this play. Businesses have another. They’re the good guys. Cyber-criminals have another role, and they’re the bad guys, although at this point we are just starting to understand that they exist.

The next act probably began roughly when spam started to choke the Internet. This was followed by phishing and the more sophisticated types of identity theft that we see today. At this point, the bad guys (the cyber-criminals) seems to have the upper hand over the goog guys (businesses that want to use the Internet for communications). That's probably where we are today. Things don't look good for the good guys at this point, and there doesn't seem to be any way out of their troubles.

The final act probably hasn't started yet. The resolution that we'd like to see, of course, is that the good guys win, but this probably isn't happening yet. Cyber-criminals still seem to be fairly successful. One indication that this is true is the fact that the law of supply and demand continues to reduce the street price of a complete identity. In some cases, a complete identity is worth as little as $1 as the amount of sensitive information disclosed in data breaches makes lots of the sensitive information available. It’s certainly possible for the good guys to win so that we get back on track to the way that the third act is supposed to end, but we don’t seem to be heading in this direction. We’re probably still stuck in the second act. Maybe that's to be expected because the second act typically takes quite a while to finish.

Sports cars and PKI

I've known several people who aspired to one day own a Corvette. Curiously, everyone that I've known to have actually bought one ended up rarely driving it. I'm not sure why they do this. Maybe they can't stand to see their Corvette dirty. Maybe they don't want to take the chances of them getting damaged in an accident. Maybe they just want to save money on insurance by rarely driving them.

On the other hand, it could be the case that the people that I've known aren’t representative of Corvette owners. I've only known a few people who dreamed of one day owning a Corvette and then managed to actually buy one one day, and such a small sample probably won't give you enough information to find any significant trends.

On the other hand, industry analysts estimate that most of PKI software ends up much like those undriven Corvettes. Apparently roughly half of PKI software ends as "shelfware," software that's purchased but never deployed. And just like the owners who don't drive their Corvettes must have a good reason to do so, I'm sure that the people who bought PKI software and didn't deploy it also have good reason for doing so.

I can almost understand why someone would buy a Corvette and not drive it much. After all, many people could probably pass many enjoyable hours admiring a Corvette as it sat in their garage. On the other hand, I don't understand at all why someone would buy PKI software and not use it. People almost certainly take their Corvette for a test drive before buying it. Don't people try a demo copy of PKI software first and make sure that it works in their environment and is at least somewhat useful before buying it? If that's the case, it's hard to understand why they end up not using it.

Back in the dot-com era, the PKI projects that I worked on cost anywhere from the equivalent of 2 to about 60 Corvettes. This wasn’t all the PKI software itself. For a big implementation, you'd have roughly 20 Corvettes worth of software, another 20 worth of hardware, and another 20 or so of professional services. For smaller implementations, it was weighted much more towards the cost of the software.

In the bigger implementations, the PKI was just one part that made a larger e-commerce project work, so it was as if customers were buying an entire lot of cars and wouldn't even notice those 60 Corvettes. These larger implementations also had a definite need for the PKI, but many customers didn't even know that they were getting one because it was just one more component of a big project. And they didn't really care. They weren't really interested in the PKI piece of their project, but they were interested in the overall benefit that they would get from the larger project. These definitely didn't end up a shelfware.

In the case of the smaller implementations, there was often not a clearly-defined need for PKI software, but customers thought that it might one day help them. These probably account for the dusty, unopened boxes of PKI software that apparently still clutter shelves of IT departments. I saw several of these projects for each of the larger projects, so the smaller projects probably account for most of the PKI software purchases. Because there was really no need for them when they were purchased, it's actually surprising that only half of these ended up unused. Maybe that's the lesson to be learned from the rise and fall of the market for PKI software – don't buy software unless you have a good reason to do so, although that's also an odd lesson for people to actually need.

Perception and reality

Where I live in San Jose, there's a shortage of parking. Every house has a two-car garage, but most of the garages are used for storage instead of parking. Add a few families with three or four cars, and you have a situation where the demand for parking spaces exceeds their supply. One of my neighbors actually blames the Bush administration for our parking problems. I'm not sure of what line of reasoning led him to that conclusion. I was fortunate enough to have my wife listen to those particular details.

This is probably a case where there's a difference between perception and reality. I seriously doubt that politicians in Washington did anything that created The Great San Jose Parking Crisis, but there's at least one person out there who believes otherwise and I doubt that any amount of facts will change his opinion. His perception and reality will probably never agree.

Information security has its own set of mismatches between perception and reality. For example, there's the perception that e-mail is in danger of being intercepted and read while it's on the Internet, but that it's safe inside the firewall. On the other hand, the reality is that e-mail is definitely in danger of being intercepted and read inside the firewall. It's fairly easy for anyone on your network to watch the traffic on it, and it's also easy for mail administrators to read people's e-mail. I know of many more cases of an administrator intercepting and reading e-mail that I do of e-mail being intercepted and read on the Internet. Most security people you talk to will probably have the same story. Despite this, the perception is that e-mail is safe in the very place that it's at the most risk.

This may or may not be a serious problem. If all of your employees can see all of your data, then you have nothing to worry about, but this is probably not the case. There's almost certainly lots of sensitive information contained in some of the e-mails that are sent within any business. Your HR people probably send documents back and forth that contain all sort of sensitive information in them including salaries, social security numbers and more. Executives preparing for their quarterly board meetings probably send documents back and forth that contain all sorts of sensitive information about the financial situation of their company and its future plans. Sales managers probably send messages to other sales managers and to the sales engineers who support them that discuss the details of the deals that they're working on. All of this sensitive information may never leave your network, but you also may not want it to get into the wrong hands, and that doesn't necessarily mean that a hacker gets his hands on it. So if you're considering encryption as a way to protect sensitive information, don't forget to protect information when it's the most vulnerable, and that's when it's still in your network.

IBE as enterprise software

I frequently get asked why identity-based encryption technology is a big deal. After all, some people say, if they use it, it certainly looks and feels like any other encryption technology. This may be true, but it also overlooks the main difference between IBE and other encryption technologies, which is in how easy it is to support and operate. So while many encryption technologies may look roughly the same from the point of view of users, they're very different from the point of view of the administrators that keep them running.

The people who don't seem to appreciate the lower costs and complexity are often people who are fortunate enough to have little exposure to enterprise software. Their point of view is probably more accurately described as that of a user of consumer software, which is a very different market than enterprise software.

Enterprise software has much stricter requirements that consumer software. Enterprise software needs to have higher performance, better scalability and higher fault-tolerance than consumer software does. This usually means that it's also more expensive, and when the total cost of ownership is considered, it's often much more expensive. This is probably unavoidable because businesses work in a strict regulatory environment and consumers don't.

If a consumer loses data on a hard drive because he forgets the password needed to decrypt it, he has probably suffered an inconvenience, but he probably hasn't broken any laws. On the other hand, businesses are required to keep some types of data available for several years and can suffer severe penalties if they don't.

It's also often necessary for someone other than the person who encrypted data to have the ability to decrypt it. If a CFO encrypts sensitive data, his business will still need the ability to decrypt that data, even if he moves on to another job at a different company. This means that key recovery is a critical feature of enterprise software but not of consumer software. Consumers might even view key recovery as undesirable because it can give someone other than them the ability to decrypt their encrypted data.

It turns out that IBE has definite advantages when it comes to keeping encrypted data available for a long time and supporting the recovery of lost encryption keys. With most encryption technologies, to be able to implement key recovery you need to keep a secure database of all the decryption keys, and if you lose any of these keys, you can also lose the data that was encrypted with it.

On the other hand, all IBE keys are calculated when they're needed from a single IBE master secret. This means that you don't need to store any decryption keys at all, but you can still recover encrypted data when it's needed. And all you have to backup is the IBE master secret, and you can recover an IBE system that's lost or destroyed in any way.

Because you don't need to securely store decryption keys, the secure database that's part of other encryption systems isn't needed with an IBE system, which makes the IBE system simpler and cheaper. This is a feature that only enterprise users will appreciate, because it's not really something that consumers need to worry about.

PKI standards

In a perfect world, all standards would be useful and reflect a consensus of experts. Unfortunately, we don't live in such a world, so some standards aren't very useful. This makes things tricky for vendors who have to explain to customers why they don't follow certain standards. A good example of this is ISO 15782-1, Certificate management for financial services – Part : Public-key certificates. Section 6.3.4 of this document has the following requirement for certificate authorities:

c) ensure that there is no duplication of the requester's distinguished name with that of any other entity certified by the CA

This means that once you get your first certificate, you can't get another one, which is a requirement that makes other best practices impossible. It's common, for example, for users to have three different certificates: one that's only used for encryption, one that's only used for digital signatures and one that's only used for authentication.

But if you follow ISO 15782-1, you can't get three certificates for the same person unless the certificates are requested for different names. So while you can't get three certificates for "Bob," you could get three certificates for "Bob, the guy who needs to encrypt," "Bob, the guy who needs to use digital signatures" and "Bob, the guy who needs to authenticate." Most systems don't give users such names, and I'm not sure that modifying your naming scheme to work this way is even a good idea. This makes it very unlikely that any CA is going to follow ISO 15782-1.

This requirement seems to also make it impossible to get a new certificate after a certificate expires. After all, the user with the name "Bob" is still the user with name "Bob" after his current certificate expires. The workaround for this is even worse. You could have a user "Bob, the guy with certificate number 8675309," and change his name to "Bob, the guy with certificate number 8675410" when he his old certificate expires and he gets a new one, but this is an even wore idea than changing the name to reflect the use of a certificate. Another workaround is to have a user "Bob, the guy living in the year 2008" and another user "Bob, the guy living in the year 2009," but that's not really a good idea either.

So there seems to be no reason for a reasonable PKI product to actually follow ISO 15782-1. It's probably too much work for vendors to try to explain why following ISO 15782-1 doesn't make sense, so they're probably more likely to just have an option for their CA products that puts you into ISO 15782-1 mode, even though absolutely nobody will ever run their product in that mode.

Virtual risks

There's often a big difference between perceived risks and actual risks. Understanding the difference may be important to people in the information security industry because people probably buy security products to mitigate perceived risks instead of actual risks. Even more tricky to deal with are "virtual risks," in which there's no easy way to determine what the real risk is or when experts can't agree on the nature of the risk.

One area in which it's not clear what type of risk really exists is in deciding whether or not cell phones pose a health threat. The Interphone study, a six-year study that cost $30 million and involved scientists from 13 different countries, tried to assess whether or not such a threat exists and come up with very mixed conclusions. Some researchers are claiming that the study showed that cell phone use seems to prevent certain types of cancer. Others are claiming that the study showed there's no connection between cell phone use and cancer. There's apparently no consensus on what the data collected by the study really means. In the absence of a meaningful scientific consensus, people will probably decide what to do based on what they think the risk is, so the issue of cell phone safety may soon enter into the realm of virtual risk if it isn't there already.

An even stranger situation seems to have happened in Sweden, where some people apparently have "electrosensitivity," or the unfortunate situation that electric fields cause them pain. The Swedish government has recognized this as a legitimate disability and will pay to have the houses of sufferers shielded. The catch is that electrosensitivity is totally psychosomatic. The discomfort felt by sufferers of electrosensitivity is real, but it's also not actually connected to the presence of an electric field! So this may actually qualify of a real risk, although it's certainly different than the risks that we usually worry about.

How important is IBE?

I frequently get asked why people should care about identity-based encryption. Because I work for a company that sells products that use IBE, I might give a biased answer, so a more independent point of view might be useful. So instead of the opinion of one person who definitely isn’t impartial, why not look at the broader cryptographic community's interest in IBE?

One way to do this is by using Google Scholar. Google Scholar can tell us how many times a particular paper has been cited by other papers, which can give us a rough idea of how important a paper is. Papers that are important are frequently cited, while those that aren’t as important are cited as frequently.

How important does IBE look when we use this metric?

Two of the most cited papers in cryptography are probably those that first described the Diffie-Hellman and RSA public-key schemes. The original Diffie-Hellman paper has been cited 5,644 times since 1977, or about 182 times per year. The original RSA paper has been cited even more often: 6,443 times since 1978, or about 215 times per year.

The paper by Boneh and Franklin that described what's commonly agreed to be the first practical and secure IBE scheme hasn't been around as long as the Diffie-Hellman or RSA papers. The Boneh and Franklin paper wasn't published until 2001, or only seven years ago, but it has been cited 2,011 times since then. That's roughly 287 times per year, which is more often than either of the other two that we’ve mentioned.

So if the interest by other cryptographers is any indicator of how important IBE is, then it certainly looks like the consensus is that it's at least as important as the Diffie-Hellman and RSA schemes.

Crypto snake oil

The term "snake oil" is often used to describe cryptography that does not actually provide the level of security that its proponents claim. The origin of this term is somewhat unclear, but one story is that it can be traced back to one of the traditional remedies for joint pain and inflammation that was brought to the US in the nineteenth century by Chinese immigrants. The fat from Chinese water snakes is high in eicosapentaenic acid (EPA), which has been shown to have some medicinal properties, so there may be some basis for believing that the traditional remedy actually had useful effects. Like the effects of many medications, however, the benefits from the traditional snake oil were subtle and varied significantly from person to person, making it difficult to rigorously prove the effectiveness of the remedy.

The fat of American rattlesnakes has a much lower concentration of EPA, however, so that when copies of the traditional remedy were made in the American West using local ingredients they turned out to be less effective than the original. Consumers could not distinguish between the two types of products, a fact that was quickly exploited by unscrupulous merchants who sold the ineffective snake oil to unsuspecting customers. Eventually this behavior became so widespread that the term "snake oil" became generalized to other products, ones that made claims of effectiveness that could not easily be substantiated by consumers and should thus be suspected of being false or misleading.

Whether this is the accurate history of the term or little more than a folk etymology, the connection to cryptography is fairly clear. Some products that provide little or no protection against a skilled adversary are sold as providing a high level of security, and most users of cryptography cannot tell the difference between secure and nonsecure versions of the technology. It seems that cryptography actually has many properties in common with snake oil, so it may be accurate to say that although cryptography may not actually be snake oil, it is very much like snake oil in some ways. And this observation is not limited to the unconventional techniques that are often labeled as such; it also includes cryptographic technologies that have withstood significant scrutiny by industry experts.

Two factors made it easy for unscrupulous vendors of ineffective snake oil to sell their product to unsuspecting customers: it was difficult for customers to distinguish between effective and ineffective versions of the product and the seller of the snake oil was also the person providing the medical advice to his customers. This situation made it extremely tempting for vendors to cheat, a temptation that many were unable to overcome. This is very similar to the situation that we still see today. Providers of car repairs and medical services both recommend purchases to their customers as well as provide what is purchased. Even after a purchase, though, it is not always clear that you really needed it. Your car may have continued to operate without a particular repair, or you might have recovered from an illness without the medication that your doctor prescribed for you. The temptation to cheat can be significant in these cases, and some studies have suggested that both car mechanics and doctors recommend a significant amount of services that their customers do not really need. Could cryptography fall into the same category?

Economists divide goods into three types: search goods, experience goods and credence goods. Search goods have properties that are easy to check before you consume them. If you are in the market for a red car, for example, it is easy to check if a potential purchase is really red. Very few, if any, information security products fall into this category.

Experience goods have properties that are not obvious before you buy, but have properties that are easy to verify after you consume them. If you are looking for a car with a certain fuel efficiency, perhaps getting at least 35 miles per gallon under your typical driving conditions, you cannot tell this by looking at the car itself (although this is why laws mandate this information be provided to consumers), but you can easily test it. Many security products are probably experience goods. You cannot tell before you deploy it whether or not antivirus software or an intrusion detection system (IDS) will really protect your network, for example, but you can observe warning messages and review the logs of the products after they have been deployed to verify that they are actually working.

Credence goods have properties that cannot easily be checked, either before or after they are consumed. Organically grown produce and meat from animals raised in humane conditions are examples of credence goods; it is very difficult to verify these particular properties, even after you consume them. Many medicines, including the historical snake oil, are also credence goods, because it is difficult to tell if your recovery was really due to the medication, a placebo effect, or even simply your body recovering on its own.

Products that implement cryptography are probably credence goods. It requires expensive and uncommon skills to verify that data is really being protected by the use of cryptography, and most people cannot easily distinguish between very weak and very strong cryptography. Even after you use cryptography, you are never quite sure that it is protecting you like it is supposed to do. It is always possible that a clever adversary could develop an attack that lets him defeat the cryptography that you are using, and he could then carry out this attack, perhaps reading encrypted messages, and you would have absolutely no idea that he was doing it.

Products cannot always be classified as purely search goods, experience goods or credence goods, and real products often have aspects of each category. Cars have some search characteristics, like their color, and some experience characteristics, like their fuel efficiency. Similarly, information security products can have aspects of more than one category. We can easily review its logs to verify that a deployed IDS is stopping some attacks on our network, so it has some experience characteristics. At the same time, the tradeoff between Type I and Type II errors that you need to make for an IDS means that a deployed IDS is probably also missing some attacks on your network that you will never be informed of. The fact that this rate of missed attacks may be acceptably low although we cannot actually verify it also gives IDS systems some credence characteristics.

On the other hand, cryptographic products seem to have many characteristics of credence goods and few characteristics of other types. You certainly cannot tell before you test it that such a product will operate as advertised, so there are probably no characteristics of search goods in these products. And because it is expensive and difficult to verify that the encryption provides strong protection to information or that a digital signature is really difficult to forge, even after it is used, cryptographic products show more characteristics of credence goods instead of experience goods. This uncertainty in quality that is characteristic of credence goods can lead to unusual results: prices that are lower than expected and are fairly uniform, even in the face of significant quality differences.

If consumers of a product cannot easily distinguish between high-quality and low-quality goods, even after they have consumed the product, we should expect that vendors cannot easily differentiate their products from competing products. In this case, we should expect prices of competing products to be roughly the same. Consumers will not be aware of the deficiencies in low-quality products, so producers of low-quality products will tend to overcharge for them. Similarly, competitive pressures will keep down the price of high-quality products. George Akerlof first described this situation in 1970 in his classic paper "The Market for 'Lemons': Quality Uncertainty and the Market Mechanism," and eventually won the Nobel Prize for Economics in 2001 for his work in this area. In the worst of these situations, the low-quality products will actually drive the high-quality products from the market as vendors of the high-quality products refuse to sell their products at the low price that the market forces upon them. Standards like Security Standards for Cryptographic Modules (FIPS 140-2) are designed to avoid such market failures and provide an indicator to customers that they are buying high-quality cryptography. Such products are guaranteed to be the modern equivalent of snake oil made from Chinese water snakes.

German farm animals in software

eierlegende Wollmilchsau

egg-laying wool-milk-sow, or a pig that lays eggs, in addition to making wool and milk

Developing enterprise software is tricky. In addition to being able to operate in the complicated IT environments that have grown and evolved over time, enterprise software also has to address the many, and sometimes conflicting, requirements that users have. In some cases, it seems that the best reason for studying formal logic in school isn't to understand what rarely-used terms like modus ponens and modus tollens mean. Instead, it's needed to help you reconcile requirements that can be represented as "P AND NOT P" in the language of formal logic because that's a reasonable way to model many customer requirements.

It's even more difficult than dealing with multiple conflicting requirements, because customers don't always give accurate or complete requirements to vendors. I was at a meeting recently where a customer of a particular vendor's key management solution mentioned that the key management technology was useless to them because it didn't support key hierarchies with more than six levels. The surprised vendor walked away grumbling that the customer had never mentioned this problem before, and was more than slightly upset that the customer chose to mention this problem in a public forum instead of bringing it up with either the vendor's support team or the sales representative that's responsible for that customer.

Most software vendors try fairly hard to provide customers with useful products. Voltage certainly does. Our product managers are routinely in their offices until fairly late at night trying to work all of the requirements that they're aware of into the development schedules for their products. Some of this work is probably reconciling conflicting requirements, or trying to figure out if they should really try to make an eierlegende Wollmilchsau. I know that I spent a fair amount of time on these problems when I was a product manager. That was several years ago, at the time of the dot-com boom, but it seems that that aspect of the job hasn't changed since then. I suppose that's part of the reason why product managers are worth what they're paid.

Black cloth and compliance

Regulatory compliance has driven the information security industry for the past few years. According to the Ernst & Young Global Information Security Surveys, compliance has topped the lists of concerns of CIOs since 2005, and it seems likely to stay in that position for quite a while. Somewhat surprisingly, it's replaced all individual security threats like viruses, spam and malware in that top position. So being regulatory compliant is apparently of more interest to CIOs than actually worrying about real threats. That might not be bad in itself, but it certainly can cause problems.

If a regulation is written well, then complying with it should get people to do the things that they should have been doing all along. If a regulation is not written well, or it allows compliance without doing anything useful, then we're probably better off without it. This was probably the case in a previous job that I had.

In this particular job, we dealt with lots of classified information. We had to handle this classified information very carefully, locking it in high-security safes at night, for example. That was until the number of safes needed to hold the information became unwieldy. When that happened, our security office developed an innovative way to work around the lack of safe space, and this involved large pieces of black cloth.

So after this new regulation was created, we then had two choices for storing classified information: we could either lock in it safes, or we could cover it with a black cloth when we went home at night. Either way put us in compliance with the regulation. One approach seemed to provide a reasonable level of security, but one didn't. The intent of the regulation was to protect classified information, but covering it with black cloth didn't seem to provide much actual protection for it. On the other hand, covering your desk with black cloth was certainly easier that locking things up in a safe, so it was more popular with employees than the alternative.

Complying with the many data security and privacy regulations seems to offer companies a similar set of choices. If they have areas that need work, they can either become regulatory compliant by increasing the overall level of security in useful and meaningful ways or they can just do enough to meet the minimums required by the regulations. Just like black cloth was more popular than high-security safes, I wouldn't be too surprised if doing the bare minimum to become regulatory compliant is more popular than the alternative.

New tools for terrorists

Terrorism is one of the more serious threats that national governments have to deal with these days. Fortunately, academics have thought about what sort of dirty tricks terrorists may try next and how to prepare for them. Here's what one paper said:

"If recent trends in terrorism have taught us anything, it is that terrorists are nimble actors who can be innovative when necessary. At the same time, technological development is inherently dynamic, with one of the negative externalities of this dynamism being the opportunities it can provide for malefactors. New technologies include cheap, accessible sprayers to disperse chemical agents, nanotech, proteinacious microspheres, aerosol vaccine delivery, bioinformatics, SNP's (single nucleotide polymorphisms) and Bose-Einstein condensates."

Bose-Einstein condensates? That's a state of matter that you get when you cool things down to temperatures of a few nanokelvins. When you get things very cold, enough atoms collapse into a single quantum state that you can actually see quantum effects. Liquids will crawl up the sides of a bottle, for example, because there's essentially no friction between the condensate and the bottle.

This doesn't sound like a good weapon for a terrorist to use. The equipment needed to keep a few thousand atoms of Bose-Einstein condensate cold is pretty big. It's definitely not the sort of thing that a terrorist can sneak past the TSA and onto an airplane. And if they could, what could they do with their exotic matter to cause trouble?

There is, however, a bizarre effect that's been called a "bosenova" that can occur when you put a Bose-Einstein condensate in the right kind of magnetic field. The word is based on the word "supernova," because the magnetic field can make the Bose-Einstein condensate fly apart in a dramatic explosion. Physicists don't seem to fully understand why bosenovas happen yet, but I doubt whether they're a suitable weapon for a terrorist to use.

In addition to having the equipment needed to make the Bose-Einstein condensate, you also need specialized equipment for making the precise kind of magnetic field that's needed to make the bosenova. And even if you have all of this equipment, it takes a huge amount of energy to make just a few thousand atoms of Bose-Einstein condensate. None of this equipment is cheap, and it's definitely not the kind of stuff that the average person could put together, even with a few million dollars in funding. I think that terrorists could probably find a better use for their time and money, so worrying about attacks using Bose-Einstein condensates is close to the bottom of the list of things that I worry about.

Are security products lemons?

George Akerlof shared the 2001 Nobel Prize in Economics for his analysis of markets with asymmetric information. Akerlof's 1970 paper, "The Market for 'Lemons'," describes how markets in which the seller has more information than the buyer tend to fail. His reasoning, when applied to used cars, gives us the following situation.

Suppose that all used cars are worth $10,000 if they are in good repair, but half of them ("lemons") actually need $2,000 worth of repairs, yet buyers cannot tell the difference between the good cars and the lemons. In this case, we should expect buyers to pay $9,000 for a used car, since they expect to have to spend an average of $1,000 on repairs. So the imperfect knowledge of the buyers has set the market price of used cars at $9,000. But at this price, those who have cars that are actually in good repair will not be inclined to sell their cars. After all, their car is worth $10,000, but they can only get $9,000 for it. This means that all of the cars offered for sale at $9,000 will be the lemons, and the difference in information between the buyers and sellers has resulted in a situation that benefits only those who are selling the lemons. The declining quality of the cars offered for sale will eventually result in the lowering of buyers' expectations, and as the market becomes dominated by lemons it may even fail altogether.

Information security is similar to the used car market in that there is often a considerable difference in knowledge between buyers and sellers. Corporate security staff are typically extremely busy supporting their users and often do not have time to learn the details of exactly how many security technologies work, while the firms that produce security technologies need to understand the same technologies at a fairly significant level to make products that function and interoperate with others. This makes it extremely easy for knowledgeable security vendors to make claims that their customers do not have the expertise to challenge. If an imbalance in information exists between the buyers and sellers in a situation like this, microeconomic theory predicts a market failure, and the way to prevent this failure is to correct the imbalance of information.

To avoid a market failure for security products, we need to reduce the imbalance of the information between vendors and their customers, much like the market for used cars has developed ways to deal with its own challenges. One way to address this problem is for security professionals to take the time to gain substantial knowledge of security technologies and the products that implement it. Unfortunately, corporate security staff are not always able to invest the time and effort that is required to thoroughly learn a new technology before they need to implement and support it.

An alternative to developing in-house expertise is for the buyers of security technology to hire an expert consultant to help them through the acquisition process. A good consultant can help them ask the right questions of a technology vendor, filter the responses for marketing hyperbole and intentional omissions, and prepare the buyer of the technology for the potential challenges that they will face when implementing the technology. It is even possible that having a consultant on their side can tip the balance of information in favor of the buyer and away from the seller.

In the market for consulting services, however, we have the same problem that we have in the market for other goods and services: how do we know that a consultant is not the consulting equivalent of a lemon? In many cases we are trying to find someone with expertise that is much greater than our own, so it can be particularly hard to accurately judge their qualifications. This is why finding consultants is often handled through trust relationships. Security managers needing specialized consulting services can use their personal networks to get recommendations for qualified consultants, or they can rely on the judgment of someone else whom they trust. This is the model that accountancies successfully leveraged for many years before regulatory concerns separated the auditing and consulting sides of their business.

Another alternative is for corporate staff to develop the expertise themselves. This has the additional benefit of keeping the expertise in-house after the initial purchase and deployment of the technology is complete, which tends to give the staff a better ability to provide ongoing support for the technology. On the other hand, learning new security technologies is expensive and time-consuming. Even if we do not include the cost of formal classroom training, the time and effort needed to understand a new technology can be significant. Because of this, learning a new technology to the depth required to provide the background needed to adequately understand vendor claims can be prohibitively expensive. And since not all new security technologies will be suitable for use at all businesses, unless the effort spent learning new technologies is carefully and narrowly focused, it is easy to spend time and money on learning technologies that provide little or no useful benefits to the mission of an security organization.

So the lessons from Akerlof's Nobel Prize-winning research provide insight into the importance of highly-qualified security professionals. They also provide insight into the possible implications if technology vendors are able to take advantage of a disparity in information relative to their customers. The results can be far-reaching and damaging to both the security industry as well as the economy as a whole, and security professionals should understand their role in addressing the challenges that this situation can cause.

How to eliminate spam

Industry analysts estimate that spam currently accounts for close to 90 percent of e-mail messages sent and causes billions of dollars in economic losses annually. The problem with spam is very similar to that of pollution: spammers profit from their activity at the expense of the rest of the population, just like polluters of the environment profit while annoying or endangering others. So it seems reasonable that our understanding of the economics of pollution may give us some insight into the economics of spam. The work of Nobel Laureate Ronald Coase is particularly useful for this.

In 1991, Coase was awarded the Nobel Prize in Economics for his contributions to understanding how property rights and transaction costs affect the structure and functioning of an economy. Coase showed that if we assume that transaction costs are negligible, as long as property rights are clearly defined, the equilibrium that a market will reach does not depend on who initially owns the affected property. All that will change is who profits from the transactions that lead to the equilibrium.

An example of this principle is a locomotive whose coal-burning engine showers sparks over the land that it passes. Reducing the level of sparks emitted is possible, but requires that the owner of the train incur the additional costs to purchase some sort of spark-reduction equipment. To quantify this, let’s assume that a train normally produces 10 units of sparks, but these can be reduced at a cost of $200 per unit eliminated, and that each unit of sparks does $300 of damage to the land that it passes. So if the train produces 10 units of sparks there will be no additional costs for the owner of the train, and the train will do $3000 of damage to the land that it passes. If the train produces no sparks at all, there will be additional costs of $2000 for the owner of the train, but the train will do no damage to the land that it passes.

If the owner of the train is free to shower sparks over the land that his train passes, the owners of the land will be willing to pay the owner of the train $300 for each unit of sparks that they eliminate. This situation will reach an equilibrium where the owners of the land will pay the owner of the train $1200 to reduce the sparks down to only four units, which the owner of the train will use to finance the modifications to his trains that the reduction in sparks requires. On the other hand, if the owner of the land is free to deny the owner of the train the right to shower sparks on his land, then the train owner will be happy to pay the landowner $1200 to compensate him for his inconvenience, and the landowner will then be happy to endure four units of sparks. The end result that we arrive at is the same in both cases, with the only difference being who is paying whom. And since both parties prefer the arrangement where four units of sparks are produced to any other, it will be the state that this market eventually reaches.

Coase showed that this will always happen as long as there are no transaction costs. So as long as we have clearly-established property rights, we will reach an equilibrium between a polluter and the victims of the pollution, and the equilibrium that we will reach will be the same no matter who owns the property rights to the environment.

If we apply this model to spam, we see that spammers are analogous to the train owners and recipients of e-mail are analogous to the owners of the land that the train will damage with its sparks. But in the case of spam, there is no way for spammers and recipients of e-mail to reach an agreement that limits the amount of spam to a mutually-acceptable level. First, there are no property rights to enforce; neither the spammers nor the legitimate users of e-mail can claim any exclusive right to use the Internet for messaging. Next, there is no efficient way for spammers to reach an agreement with their victims. Because of this, the amount of spam sent remains unchecked by market forces, as does the annoyance suffered by users of e-mail.

Thus Coase's result provides an easy solution to the problem of spam: define ownership of the Internet and the rights to use it. Once we do this, market forces will then drive the amount of spam that is sent to an acceptable level, with slight inefficiencies possible due to the transaction costs involved. And since the equilibrium that the market will reach does not depend on to whom we assign ownership of the Internet, we will even end up with the same reduction in spam if we decide to assign the ownership of the Internet to the spammers – a truly remarkable result.

Applying risk homeostasis

Information security is the application of risk management principles to information technology, so we should expect that results for the broader field of risk management should give useful results when specialized to information security. The concept of "risk homeostasis," as defined by Gerald J. S. Wilde in his book Target Risk, may be such a principle. Risk homeostasis theory tells us that we need to modify the behavior of employees to have an effective information security program, something which is often overlooked in the design and implementation of such programs.

The principle of risk homeostasis tells us that people feel comfortable with a certain level of risk in their lives. So if one type of risk is somehow reduced, people will tend to adjust their behavior to compensate, perhaps accepting additional risks as they do so. Wilde's research indicates that this happens in many cases.

If risk homeostasis is indeed an inescapable part of human behavior, as Wilde suggests, then we can expect it to apply to the use of information technology as well. Traditional techniques of minimizing risk usually involve the "triple-E" of engineering, education and enforcement. On the other hand, risk homeostasis theory tells us that the motivation of users is the most important factor to consider, yet traditional approaches do little or nothing to address this, and may just reallocate risk instead of reducing it.

Risk homeostasis theory provides a way for using motivations to affect behavior, and Wilde's research has found a number of characteristics of successful risk reduction programs that are common to many such programs. Incentives play an important role in such programs, and are particularly effective at changing behavior. The common characteristics of successful risk reduction programs include the following:

1. Managerial vigor. Managerial commitment to a program should be obvious and reinforced often. This applies to any program, and information security is no exception.
2. Rewarding the bottom line. Effective incentive program should reward the outcome instead the intent. So it is better to measure the number of computer viruses that an organization is infected with rather than the percentage of computers equipped with anti-virus software.
3. Rewards must be attractive. Incentives to employees that successfully reduce the number of security incidents could include cash, shares of stock, extra privileges or extra holidays. Rewards do not have to be large to be effective.
4. Progressive incentives. It is more than four times as difficult to remain free of security incidents for one year than it is to remain free of security incidents for one quarter. So a reward for a complete year with no security incidents should be more than four times as great as the reward for no security incidents for a single quarter.
5. Simple rules. A successful information security program should be kept simple and easily understandable to all employees who it affects.
6. Perceived equity. The rewards of an incentive program should be perceived as equitable by those employees that it affects. Employees who are not eligible for an incentive for some reason should not resent the incentives received by those who are eligible.
7. Perceived attainability. Goals for which incentives are offered should be attainable. If goals are unattainable, some people will not make an active attempt to meet the goals. A goal of no security incidents at all is probably unattainable, so a more realistic goal should be used instead.
8. Short incubation period. The time period for which an employee needs to remain free of security incidents in order to be eligible for an incentive should be relatively short. Delayed incentives are not valued as much as ones which are immediate.
9. Reward both group and individual performance. Incentive programs should be designed so that they strengthen peer pressure towards a goal of effective information security. Incentives to entire groups as well as to individuals are also useful to this end.
10. User participation in program design. Any incentive system should be developed in cooperation with those who will be affected by it. People are more likely to achieve goals that they have helped define.
11. Prevention of incident under-reporting. An effective incentive program should counter any tendencies to not report security incidents. If a computer is infected by a virus, for example, not reporting the incident should be penalized more than just getting a virus.
12. Reward all levels of an organization. Workers, supervisors and middle-management should all be eligible for incentives for meeting their information security goals. This creates a more cohesive and pervasive orientation towards being security-aware.
13. Appropriate information security training. Although training for security is different from motivating towards security, some studies suggest that it helpful for employees to be told what specific behaviors will help avoid security incidents.
14. Maximize net savings or benefit/cost. In the planning an incentive program, there will not be enough resources to reward all behavior, so some thought should be given to the question of exactly what behaviors are rewarded. Be sure that the behavior that is encouraged is that which provides the greatest return for the organization.
15. Effective research. Like any health and safety program, an incentive plan for information security should not be casually introduced. Understand what factors an incentive program can affect, the benefits from the possible changes, as well as the costs of doing so, before implementing any incentive program.

By using an incentive program with the characteristics that Wilde’s research indicates are the most effective, you may maximize the chances of changing employees' behavior so that information security risks are minimized. You might want to give such elements serious consideration when reviewing the status and future direction of existing information security programs.

Credit card fraud

There's a lot of credit card fraud. Estimates that I've seen recently estimate the total amount if it to be several billion dollars per year. Despite this, credit cards are wildly popular with banks, merchants and consumers. This means that it's probably the case that we're better off with them than without them. It also means that there's probably more than several billion dollars of value from credit cards, or more than enough to outweigh the massive amounts of fraud that they allow. To understand this, it might be useful to look at the history of credit cards.

Roughly 100 years ago, most consumer transactions were in cash. To make things easier for consumers, many businesses introduced proprietary charge cards in the early 1900s. These were only valid at one particular merchant. Each oil company had its own card that was only valid at its gas stations, and each department store had its own card that was only valid at its stores. In addition, these cards required users to pay their bills in full each month.

These cards were much more convenient than using cash. They reduced the need to get cash from a bank and allowed for one convenient payment per month. On the other hand, they also had a serious limitation: they required a separate card for each merchant. This meant that they weren't very useful to travelers.

The ability to pay in installments was added to charge cards in the 1930s, and in the 1950s, Diners Club became the first card that was accepted in a large area. By 1958, American Express was also issuing similar cards. These cards were still aimed at travelers, so you could expect to be able to charge meals and hotel rooms with them, but you couldn't expect to use them at most stores. In the case of charge cards, the card issuer also processed all transactions, both with consumers and merchants. This required a merchant to have a relationship with each bank that issued a card if he wanted to accept the card for payment.

The first general-purpose credit cards were the BankAmericards that were issued in 1966 by the Bank of America. Shortly thereafter, four other banks (United California Bank, Wells Fargo, Crocker National Bank and the Bank of California) formed the Interbank Card Association to issue the MasterCharge card and compete with the BankAmericard. These cards added an additional level of complexity to the card processing. They allowed the card-issuing bank to be different from the merchant's bank, and created a centralized system to settle transactions between the two. This finally provided the infrastructure that allowed the widespread use of credit cards that we see today. Along the way, the BankAmericard evolved into Visa and MasterCharge evolved into MasterCard.

At each step in this evolution, there were more opportunities for fraud. These opportunities were the fewest when each merchant had its own charge card and are the greatest in the current four-party model that's used by credit card companies today. But even though there is billions of dollars of credit card fraud today, it's only a small percentage of the trillions of dollars of purchases that credit cards are used for.

It's almost certain that the additional fraud that each step has allowed has been outweighed by the benefits that the additional convenience allowed. How much would it cost merchants to each operate their own charge card? The overhead of tens of thousands of such cards is probably much greater that the fees that merchants currently pay on credit card transactions and you'll probably find few merchants who want to return to the older system. The additional convenience, both to consumers and merchants is much greater that the billions of dollars of fraud that the system allows, and we're much better with credit cards that without them.

Rationalizing Illegal Activities

One evening I had a conversation with someone who mentioned he had downloaded a movie and watched it. Upon futher examination it turned out this had been an unauthorized download. He paid nothing, he never got permission to download it. I suggested that what he did was possibly illegal, or at least unethical. He responded with what I consider rationalizations.

First, he said, he never would have paid for the movie if he had not been able to download. In other words, it wasn't his kind of movie, so the production company would never have gotten his money anyway. So I asked him, "Would you sneak into a movie theater? How about if it was a movie you would not pay to see? Suppose you sneak in and find plenty of empty seats? When you sneak in to a movie you'd never pay to see anyway, you do not deprive the theater or movie producers any money, so why not? How about a can of caviar? Would you ever buy caviar? No? So is it OK to take a can of caviar from a grocery store? They'll never get your money whether you take the can or not, so why not take the can?"

Another argument he made was that the production company will make so much profit on the movie, one guy downloading it for free is not going to affect their bottom line. "Only one guy? Are you the only person downloading? If not, how many people doing this would it take before it becomes a bad thing? Ten, twenty, one million, 100 million? If it's 100,000, then is the wrongness split among the 100,000, so that you have only committed 1/100,000th of a wrong? Or is it wrong for you to be one of 100,000? Or is the wrongness attributed to the 100,000, and each individual bears no responsibility?" I also asked, "Honda is making huge profits these days. If you steal a Honda they'll still make lots of money. So is it OK to steal a Honda?" Of course not, he replied, but the movie and the cars are different.

Cars are a big ticket item. So would the situations be different if we were talking about cans of caviar? How about coffee mugs? Or a cheap key ring? How about a post card from Disneyland ("Hey, it's only 20 cents and I'm actually providing them with some advertising.")?

These things are different. When you make an unauthorized download of a movie (as opposed to stealing an actual physical copy of the film in a container), that does not prevent the production company from selling another copy of the movie. When you steal a car, a cell phone, a key ring, or a post card, the seller no longer has the ability to make money off of that item. (This is why unauthorized downloads are copyright infringement, not theft.)

However, I still think the reasons given are rationalizations. I think that people can rationalize improperly downloading movies and music because there is no tangible thing that is taken. It's easier to overlook ethics when nothing touches your skin. Also, the actual act of downloading is fairly easy (well, for someone who makes the effort to find out how to do it). If you had to develop some skills or use your fingers to actually touch the thing you were taking, if you could see the thing as a physical entity, it would not be so easy to rationalize away. Another element is how much you like the think your taking. The more you want something, the easier it is to come up with a reason to get that thing by "alternative means." And, of course, so many people are doing it ("so many people are getting it for free, I'd feel like a sap if I paid for it").

"The record companies are big corporations, they won't miss it. They're evil, they've been stealing from the artists for years." The record companies steal from the artists, so it's OK for you to steal from the artists as well? And don't we hear that excuse given in lawsuits? "Sure the guy was drunk and should have never been smoking while he was siphoning gas from the the big corporation's car, and sure what he was doing was illegal, but we'll find for the plaintiff because it's a big corporation, they have plenty of money, the insurance company will pay for it so no one is hurt anyway." When we hear that we think it's wrong.

"Other artists are figuring out how to make money in this environment, so if someone won't adapt, that's not my fault." Newspapers are finding the new environment of the internet makes it more difficult to make money, some are adapting to it with online editions. But if a newspaper doesn't adapt, does that mean it's OK to take a newspaper without paying for it?

The issue of downloading material is not cut and dried, the whole world of intellectual property is complex made even more complex by the internet. I'm not going to say there is a moral, ethical, and legal absolute on this question. However, making rationalizations is the wrong way to come to a solution.

Some thieves rationalize their activities by saying they only steal from people who can afford it, or that they need to put food in their bellies and the capitalist system we have makes it impossible for them to do so unless they steal. Some even say that it is your responsibility to prevent the theft: if someone is able to steal something from you, it's your fault, the thief bears no responsibility. (I recall an English soccer hooligan who, after 39 people were killed in Heysel stadium in 1985 when the hooligans launched an attack on Italian fans, placed the blame on the Italian fans because they didn't fight back hard enough.)

We see these rationalizations for what they are, very few people would accept them as valid ethical justifications. We know the thieves employ the rationalizations to allow themselves to continue doing what they're doing without suffering the emotional pain of a guilty conscience. (Well, some thieves, others have no ethical qualms about doing what they do.)

So when it comes to improper downloads, don't rationalize.

Why FFSEM?

Unless you're Grace Owen of Concord, New Hampshire (the woman who's famous for having the lowest Social Security number of all – 001-01-0001), you probably want to keep your Social Security number private. Sometimes this is out of your control, and you rely on the banks and other businesses that need your Social Security number to treat it carefully so that it's not exposed to identity thieves. Some of the businesses that have your Social Security number need to keep it around for a long time. If your college uses it as a unique identifier, for example, they need to keep it around for as long as you might need to access your college transcripts. Health care organizations also need to keep medical records for a long time. Banks also do.

Because each of these organizations need to keep your Social Security number for many years, they're also the ones who will have to deal with the problems of keeping your records compatible with many generations of computing technology. This is a difficult problem, and it's even more difficult if they want to protect your Social Security number by encrypting it. This is because both the size and the format of the Social Security number changes when it gets encrypted.

Let's use Ms. Owen's Social Security number as an example. It might be stored in a database as 001010001, which is nine decimal digits. This might get encrypted to ciphertext that looks like this:

b648n6GjdbvHuLCBQIDUlLN5tdtC4yIM+3PMpGKDJobUbeubKryL77c3aitxaaCuT4S?64b

You can try this at this web site, where there's a JavaScript implementation of AES that you can use to encrypt data and see how the ciphertext looks in various formats. This ciphertext was created from the plaintext "001010001" using the text passphrase "password" and encoding the ciphertext in Base64. If you try it, you'll get a different result because a different random seed called an "initialization vector" or "IV" is used for each encryption. The format will still be roughly the same, however.

This ciphertext is clearly not just nine decimal digits. It's much longer and it's no longer made up of just digits. If you have a computing environment that has been around for many years, there's a very good chance that this ciphertext will cause a problem with some part of it because it's expecting nine decimal digits instead of a longer alphanumeric string. One way around this problem is to AES in a way that keeps the format of the original plaintext. If we can do this, we can then encrypt a nine-digit Social Security number so that the ciphertext is also another nine-digit number. Or we can encrypt a sixteen-digit credit card number and get a ciphertext which is also a sixteen-digit number. Either of these will be much easier for legacy environments to handle.

A new mode that's recently been proposed for AES, the so-called Feistel Finite Set Encryption Mode (FFSEM) does exactly this. You can see the full proposal on the NIST web site. If you're interested in the details of why FFSEM is secure, you can look at the original paper by John Black and Philip Rogaway. They have a formal proof of why FFSEM is exactly as secure as the cipher that's used to construct it. So if AES is this underlying cipher, the resulting FFSEM is exactly as secure as AES.

If you use FFSEM, things look much different. We might encrypt Ms. Owen's Social Security number into the ciphertext 812493994. (Note that the 812 prefix ensures that that's not a valid Social Security number, so we're not accidentally giving away sensitive data here.) In this case, it's very unlikely that any part of a legacy computing environment will have problems handling an encrypted Social Security number because encrypted data will look just like the unencrypted data. So FFSEM will let you protect sensitive information while minimizing the chances of fatal interactions with older systems. If you want to protect sensitive information using encryption but worry that encrypted data will cause problems in your computing envisonment, FFSEM may be just what you need.

Security and travel

"Suit the action to the word, the word to the action."

William Shakespeare, Hamlet (III, ii, 16)

Travel is fun when you're young. It's fun to see different airports, travel by plane, stay in hotels and eat at restaurants. After several years of this, however, it stops being fun and gets to be work. For me, this happened several years ago when I was a product manager. I had to do a series of press conferences announcing the release of our 4.0 product, and to do this I had to make a rather long trip. I left San Francisco, flew to Tokyo, then to Singapore, then to London, then to Washington, and then back to San Francisco. I was actually sitting in airplane seats for over 40 hours that week. When I got back, I realized that I'd had enough travel for one lifetime.

That's also when I realized that the words "travel" and "travail" are cognates, or that they both share the same history. If you trace these words back a few hundred years, you'll find that they both come from the word "travaillier," which is Old French for "to torment." If you've traveled recently, you'll probably understand why these two words are related. Apparently travel was just as bad in the Middle Ages as it is today.

The word "security" also has a history that's interesting. It comes from the Latin word "securus," which means "free from care." So although we often think of security as preventing bad things from happening, the origin of the word tells us that it might be useful to think of security as letting you not worry about things.

In the case of encrypted e-mail, for example, we often think of encrypted e-mail as something that prevents hackers from seeing the contents of sensitive e-mails. It might be more appropriate to think of encrypted e-mail as something that lets you take advantage of the ease and convenience of e-mail without worrying about what might happen if a hacker were to intercept your e-mail.

T.J. Hooper

T.J. Hooper (short for In re Eastern Transportation Co. (The T.J. Hooper), 60 F.2d 737 (2d Cir. 1932)), is a legal ruling that may have interesting implications in future legal battles that result from data breaches. In this case, Judge Learned Hand established the precedent that prevailing practice is not a valid way to avoid liability.

When two barges sank and their cargoes were lost in heavy weather, the owners of the lost barges and their cargoes claimed that their loss was caused by negligence on the part of operator of the tugboats. Their claim was that if radios that could receive weather reports had been installed on the tugboats then their losses would have been avoided when the tugboat operators were warned of the heavy weather. Because the tugboats did not have radios installed, this meant that the owner of the tugboats was negligent for not using them.

The owner of the tugboats claimed that they couldn't be expected to have radios installed because they were new technology and their use was not common. In the T.J. Hooper case, the operator of the tugboats was found negligent. This set the general precedent that the fact that technology is new and its use is uncommon does not mean that not using it is a way to avoid liability.

Today, data breaches are very common, yet the use of encryption is not very widespread. There may be good reasons for not wanting to encrypt information. Encryption has historically been difficult and expensive. This isn't the case any more, but when it was, it was a valid reason not to use encryption. Now that encryption is easy enough to use, however, the precedent of T.J. Hooper becomes relevant. Prevailing practice is not a valid way to avoid liability, and just because many other organizations aren't protecting their information with encryption doesn't mean that you shouldn't do it yourself. You can still be found negligent if that's the case. Not using encryption because there's no valid business case for it makes sense; not using it just because other people don't use it doesn't.