Superconductor

Gresham's law

There's a little-known observation called "Gresham's law" that may or may not have some relevance to today's security market. Gresham's law says roughly that the introduction of debased currency will tend to make non-debased currency disappear from circulation when people tend to hold onto the currency with more intrinsic value and spend the rest. It's named for Thomas Gresham, an advisor to Queen Elizabeth, but Gresham wasn't the first to note this behavior. Nicole Oresme described it in his 1357 book De origine, natura, jure et mutationibus monetarum.

This principle doesn't apply to all cases where low-quality and high-quality alternatives compete in the marketplace. It also needs some sort of regulation to make it happen. In the case of coins, there are laws that say that both the non-debased coins and the debased ones are worth the same amount, so the non-debased ones tend to disappear from circulation. In cases where there is no requirement that the low quality alternative be worth the same as the high quality alternative, Gresham's law doesn’t predict that the high-quality alternative will disappear.

In the case of the PCI DSS, however, we may have a situation where Gresham's law does hold. This is because compliance officers are often looking for a solution that lets them pass their PCI DSS audit instead of a solution that actually provides strong and useful security. The PCI DSS now acts like a regulation that makes the high-quality and low-quality products equal because they both will let their users pass their PCI DSS audit. If this is the case, then we would expect high-quality security products to disappear, leaving their low-quality competitors as the only alternatives. This hasn't happened yet. Should we expect it to happen soon?

According to "Gresham's Law or Gresham's Fallacy," a paper recently written by Arthur Rolnick and Warren Weber of The Federal Reserve Bank of Minneapolis, Gresham's law isn't as true as we might think. Here's the abstract for their paper that sums up what they found:

The claim that bad money drives out good is one of the oldest and most cited in economics. Economists refer to this claim as Gresham’s law. Yet despite its seemingly universal acceptance, this claim does not warrant its status as a law. We find it has no convincing explanations and many overlooked exceptions. We propose an alternative hypothesis based on the costs of using a medium of exchange at a nonpar price: small-denomination currency undervalued at the mint tends to disappear from circulation while large-denomination currency usually circulates at premium. Examining a variety of historical episodes when market and legal prices were different, we find our “law” can explain history much better than Gresham’s.

Like most things, the applicability of Gresham's law turns out to be more complicated that you might first think, and it takes a more careful understanding of a particular situation to predict exactly what will or will not happen. If this is the case, it looks like we may not have to worry about high-quality security products disappearing because of the PCI DSS.

The hard part of the PCI DSS

Most of the requirements of the PCI DSS are really just information security "best practices." The only real exception is Requirement 3: protect stored cardholder data. The easiest way to meet this requirement is by using encryption, but many businesses that need to handle sensitive cardholder data seem to have trouble doing that. That's not too surprising. Encryption is legendarily hard and expensive to use, and there are still some encryption technologies out there for which this is true. On the other hand, there are also lots of encryption technologies for which this isn't true. Voltage makes some of these. A few other vendors do also.

Because there are encryption technologies that make it easy to meet PCI DSS Requirement 3, I was surprised to read a recent report, "Lessons Learned: Top Reasons for PCI Audit Failure and How To Avoid Them" by QSA VeriSign. In the PCI DSS assessments that VeriSign does for its clients, Requirement 3 is the area that people fail the most frequently: a full 79 percent fail it. I found that surprising. Maybe those people should talk to someone at Voltage.

Friendly names for certificates

The naming of keys is a difficult matter,

It isn't just one of your holiday games;

You may think at first that I'm mad as a hatter

When I tell you a key needs to have a good name.

It should be the one that its users use daily,

Such as "This one's for email" or "For VPN,"

Such as "This one's for signing," or "Intranet access,"

All of them sensible everyday names.

If you use X.509 certificates, one problem that you might encounter is figuring out which certificate to use. Every certificate that I have has the same name for me in them, so unless I know the expiration date or the serial number of a particular certificate (which I never do), it's always a matter of trial and error when I try to figure out which one I need to use.

In Internet Explorer, however, there's a field for "friendly name" in the Certificates window that you can open by going to Tools→Internet Options→Content→Certificates. Once you get there, however, it's not obvious how to change the friendly name. You can do this if you select the Personal tab and then select a particular certificate. Then go to View→Details→Edit Properties, and you'll see a field where you can enter both a "friendly name" and "details" for your certificate. If you do that, you'll be able to easily tell the difference between your certificates without having to know their expiration dates.

In Firefox, it doesn't seem as easy. If you go to Tools→Options→Advanced→View Certificates, you can see which certificates you have, but I can't find a way to assign a friendly name to them. It looks like you'll just have to remember whether you need to use the one with serial number 48:CB:F9:8D:65:9E:B5:84:5F:AF:A4:A8:B4:08:E9:D1 or the one with serial number 22:4D:02:80:BC:DE:AD:E7:73:81:BF:6C:74:8A:B4:BF when you want to encrypt email. Or you can just try to remember the expiration date. Neither way seems to be very useful.

Names for big numbers

Cryptographic keys don't sound that big because we usually talk about how many bits they have, which is really just the logarithm of a number. The numbers that we're dealing with in cryptography are big. Really big. They're so big that most people probably haven't heard of the names for them.

A 128-bit key, for example, represents a number that's roughly 10³⁹, or about a hundred undecillion. A 256-bit key represents a number that's roughly 10⁷⁷, or about a hundred quattuorvigintillion. The numbers that are used in public-key algorithms are even bigger. A 1,024-bit key represents a number that's about 10³⁰⁸, or a hundred thousand centillion.

If you're using a 15,360-bit RSA key, like you need to do to get the same strength as a 256-bit AES key, you have a number that's roughly 10^4,623, or a trecentillion trecentillion trecentillion trecentillion trecentillion quintrigintillion. At that point, the words don't seem to work very well and it's probably better to just think of the number as having 15,360 bits.

Why do people work on open-source software?

As every individual, therefore, endeavours as much as he can both to employ his capital in the support of domestic industry, and so to direct that industry that its produce may be of the greatest value; every individual necessarily labours to render the annual revenue of the society as great as he can. He generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By preferring the support of domestic to that of foreign industry, he intends only his own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention.

Adam Smith, An Inquiry into the Nature and Causes of the Wealth of Nations

It's not hard to create a plausible economic model that explains why open-source software exists. One argument is that enterprise software has a minimum cost associated with developing and marketing it. These costs include the engineers that write the software, the people that test it, the sales engineers that install it at customer sites, the sales people who help customers through the sales cycle, the marketing people who let customers know what's available to solve their problems, etc. The total cost of all of these isn't cheap, so if a particular application isn't worth more than that fixed cost, it can't be the basis for a profitable business.

But if there's a demand for something at a lower cost, someone will probably find a way to make it happen. It's much like minimum-wage laws. There are some jobs that just aren't worth the minimum wage, and when this is the case, people find ways to get those low-value jobs done, even if it involves breaking the law. They might hire illegal immigrants for less than the minimum wage. Or they might agree to pay someone cash to avoid the taxes that, from the point of view of the employer, are also part of their cost of labor.

On the other hand, an argument like this only describes market forces, Adam Smith's invisible hand that makes things happen. It might explain why open-source software exists, but doesn't really tell us why any particular person would make a decision to work on open-source software. That may require a different explanation. Here's one, and it's based on modeling contributing to open-source software as a tournament. It's much like the model that Stephen Levitt and Stephen J. Dubner used in their book Freakonomics to explain why so many drug dealers earn roughly the equivalent of the minimum wage.

It turns out that almost all drug dealers don't make very much money. These are the ones that actually sell the drugs on the streets. The real money is in managing an organization of drug dealers, and Levitt and Dubner describe how the entry-level drug dealers tolerate the low pay because they hope to eventually become one of the managers. In this sense, drug dealing can be modeled as a tournament that selects the most fit drug dealers and promotes the winners into the more lucrative jobs.

Maybe this model also applies to open-source software. After all, being a recognized contributor to a big, successful open-source project is also a good way to get a high-paying programming job. So it might be the case that the programmers who donate their time to open-source projects do this in the hope of becoming an open-source superstar one day. This doesn't sound obviously false, and it does give you a good way to start a conversation: "Did you know that open-source programmers are like drug dealers?"

Is AES secure enough?

There's been a lot of discussion in the past day or so about the security of the AES encryption algorithm. There's a paper by Alex Biryukov and Dmitry Khovratovich that describes an attack against AES-256 that can be done in much less time that brute-force exhaustion: 2¹¹⁹ trial encryptions instead of 2²⁵⁶. That's a huge difference. Is AES now so weak that we need to worry about it?

Absolutely not.

The attack that Biryukov and Khovratovich found also takes lots of data for it to work. Their attack that can be done in 2¹¹⁹ time also takes the same amount of data: 2¹¹⁹. That's a lot of ciphertexts.

The best estimates that I've seen say that the entire world produces a few exabytes of data per year. This estimate is actually from a few years ago, so it isn't that current. Let's suppose that the amount of data being created doubles each year. If that's the case, we probably have a few zettabytes of data being created per year right now.

A zettabyte is 10²¹ bytes, or about 2⁷⁰ bytes. That's a lot of data, but it's still a long way from 2¹¹⁹ ciphertexts. This means that an attack that takes that much data is totally impractical. Even if we assume that all of the data in the world is being used in an attack that's trying to recover a single AES key, it's still not enough. It would take roughly the amount of data that the entire world will produce in the next 50 years or so to get the amount of data that we'd need. And even then, the amount of time required is still prohibitive.

It's interesting that Biryukov and Khovratovich found a significant weakness in AES, and their work may give useful insights into how to design better symmetric encryption algorithms, but it's not the sort of weakness that anyone can actually use to actually recover data that's encrypted with AES.

The Virginian goes to the RSA Conference

Owen Wister's 1902 novel The Virginian was one of the first books that might be called a "western." It essentially defined the western genre and established many of what are now its clichés. One of my favorite parts of this book is when the Virginian ends an uprising by disgruntled cowboys by beating their leader in a tall tales contest. I'm often reminded of this showdown when I hear claims made by the marketing departments of security vendors, and it's entertaining to think of how a similar epic battle might take place today.

Imagine we're at next year's RSA Conference, drinking the free beer that some generous vendor has provided. A CISO from a big company is here. He's never been to the show before doesn't realize that he'll be swarmed by vendors if he attends an event like this one. To get his attention, the sales and marketing people from lots of security vendors make more and more outlandish claims about their technology.

There's someone there from a vendor that makes products that are designed to counter the insider threat. After a beer or two, the people at the party have forgotten that there's absolutely no basis for the claims that most attacks come from insiders, so they listen to him. He quotes some statistics from analyst reports that nobody has heard of and ends up with the estimate that over 150 percent of attacks come from insiders.

People are impressed, but take a quick break to get another beer. Surely someone can do better than that.

Next is someone from a tokenization vendor who claims that tokenization is actually more secure than encryption. Encryption is hard to understand when you've had a good night's sleep and a couple cups of coffee, and the free beer has made sure that nobody at the party is able to even come close to understanding it now. The lone cryptographer who's at the party is impressed by the daring that it took to make that claim, even to a room full of people drinking free beer, so he doesn't challenge it.

Unable to think of a way to one-up this, the other vendors gradually walk away, leaving the tokenization vendor alone with the CISO.

Why businesses aren't profitable

Conventional wisdom tells us that the global recession that we're seeing now is the result of the recent problems with financial markets. A closer look at IT industry analyst reports, however, might tell us that there's another reason that businesses aren't doing as well as they'd like to, and that's because of their use of IT. In particular, if you add up the TCO estimates for all of the IT products that a typical business uses, you'll find that the cost of their IT systems is much greater than their revenue. In other words, there's absolutely no way that a business can both use IT systems and be profitable at the same time.

This leads me to believe that one of two things has to be true. One possibility is that the TCO estimates that we often see aren't really very meaningful. Another possibility is that it's just impractical to use modern IT products because they cost more that they're worth. If the first of these two is true, then we have nothing to worry about, except perhaps wasting lots of time on TCO estimates that don't really tell us anything useful. If the second is true, then the global economy is doomed until we revert to more primitive, pre-dot-com-era technologies. Which one is more likely?

Hardware Engineers and Their Software

Over the years I have dealt with a lot of different security hardware, from tokens (PCMCIA cards, USB devices, etc.) and coprocessors, to crypto accelerators and "HSMs" (Hardware Security Modules). With the hardware product comes the software interface. If you're building a product that wants to take advantage of the chip or device, your code will call the supplied set of functions that will actually send the messages to the hardware informing it of the operations to perform.

Over the years I have complained bitterly about some of the software interfaces I have come across. I have seen some software that I thought was awful. I would be angry that a company would build a device, invite people to use it, then make the software interface so terrible.

Let me interject something here. I write software for a living. Most of the software I have written has gotten good reviews, but I must admit, there have been some bad reviews in there. Or sometimes the review was not so much bad, as the reviewer was a bit frustrated by complexity. For example, I read part of a book about Crypto APIs, and one of the APIs was BSAFE. Although I was not the original designer of BSAFE, I was a major contributor to that product. Furthermore, I'm on board with the design. I think it is a great design. (In fact, the Voltage toolkit is my design and the similarities to BSAFE are very evident, although I think I did make some improvements). Anyway, this book said that one of the best things about BSAFE is that it could do anything you could possibly want to do in crypto. The worst thing about it is that it can do anything you could possibly want to do in crypto. That made it complicated. Simple tasks were not necessarily simple. The point is, when I complain about someone else's software, I fully admit that someone can look at my designs and complain about aspects of it. I'm not saying my code has no flaws or problems for the customer.

But some of that software from the hardware vendors was terrible.

Well, now I might not be so quick to label it "terrible". Recently, I was talking with a hardware engineer. He said something that I think explains a lot of the "awfulness". He said the H/W person will design the software interface to mimic what the hardware does. Put another way, the difference between a hardware engineer and a software engineer is that the H/W engineer designs software based on what the hardware can do, the S/W engineer will design software based on what the user wants to do.

Who is the user? For the security hardware, the user is the application developer. That's the same user of the Voltage toolkit. So let's look at an example of two interfaces performing SHA-256.

Let's say you have an app that needs to perform SHA-256. Maybe it's for a digital signature, or maybe for a checksum, or maybe it's for a key derivation function. You need to digest something.

The Voltage toolkit says, "build an object that can perform SHA-256, then call Init, Update, Final. Provide the data to digest as a byte array. If you need to digest something else, keep the object around and reuse it, just call Init again to start over. If you have so much data that you want to perform the operation in parts, or maybe the data is from multiple sources and you don't want to collect it into a single buffer, call Update, Update, and so on until you have no more data, then call Final." In the end you have 32 bytes, the digest.

The interface to a hardware device might say, "provide 64 bytes and the eight h-values and the return is the updated h-values".

Great, what does that mean?

It turns out there is some rationality to that interface. You see, SHA-256 works this way.

• Start with 32 bytes, represented as eight 32-bit words, these are the h-values. Give them an initial value.

• Take the first 64 bytes of input and perform a function on them, call this function SHA256Transform. This SHA256Transform combines the h-values with the 64-byte input to update the h-values.

• Now operate on the next 64 bytes of input, and the next, and so on. Each call to SHA256Transform will use the h-values that were the result of the last call and combine them with the new input to create a new set of h-values.

• When there's no more output, apply padding. If the input data was not a multiple of 64 bytes, you need to pad so that you have a complete block on which the algorithm can operate (SHA256Transform can only operate on 64 bytes, no more, no less). Even if the input was a multiple of 64 bytes, you must apply padding (the padding scheme increases the security of the algorithm).

• After the padded block has been processed, the result is the 32 bytes that make up the last set of h-values.

Suppose you're a hardware vendor and you want to make a chip that can perform SHA-256. You'd really only do the SHA256Transform in hardware. Your chip would not do the work of breaking the input data into 64-byte blocks, nor would it perform the padding. The time-consuming and compute-intensive operation is the SHA256Transform. All the chip would be built to perform is the Transform operation.

When it comes time to build the software interface, what do you do? Do you build something that takes in byte array input and returns a digest (as the Voltage toolkit does)? Or do you put together a function call that is a "mirror image" of the hardware, namely the SHA256Transform?

A software engineer would probably say that while a SHA256Transform can be useful, that alone does not generate a digest. Most users will want to simply call a routine that takes in input and generates a digest. So the right thing to do is to perform all that "bookkeeping" as well as the transform.

The hardware engineer might say, "What do you mean? The hardware does the Transform function, therefore the interface should be the Transform function. Why should the interface do the bookkeeping if the hardware doesn't?"

The answer is that someone will have to do the bookkeeping. If the hardware interface does not do it, then the customer will. Or more precisely, each customer will. Suppose the hardware vendor has 50 customers. Each customer will write their own version of the bookkeeping code. That's 50 versions of the same code, quite a duplication of effort. Everyone has to "re-invent the wheel". Doesn't it make much more sense to do that work once?

This does not explain all the awful software I've seen come from the hardware vendors, but it does explain some of it. I don't agree with the philosophy, "The software interface is designed to do what the hardware can do, no more, no less." I suspect most people would think it is not the right philosophy a business venture should take. But at least I can understand it.

Challenges with point-of-sale devices

The point-of-sale devices that retail operations use need to be very easy to use because they're often used by relatively untrained people. I saw an example of this a few years ago when I went to the local sporting goods store to pick up a package of white athletic socks.

I handed my credit card to the clerk in the store, who swiped it through his POS device, keyed in the amount of the transaction and waited for an authorization code to appear. There was apparently a problem with the connection of the POS device to the authorization service. What appeared on the LCD screen of the POS device was a pattern of random LCD segments that looked something like this:

 

The clerk didn't recognize this as anything other than a valid authorization code, and proceeded to carefully copy this pattern into the space for the authorization code onto the credit card payment slip. Apparently, nobody had told him to expect a series of numbers for the authorization code.

I left the store wondering what other types of mistakes had happened when the store processed credit cards. I doubt that I saw the worst mistake that an untrained person ever made.

Ancient format-preserving encryption in FIPS 74

Although the format-preserving encryption algorithms that Phil Rogaway invented are very useful for encrypting data in a way that makes integrating encryption with legacy applications and complex IT environments particularly easy, it turns out that he wasn't the first to do this. An old, retired NIST document that describes how to use the DES encryption algorithm actually described a way to do it.

The NIST document that does this is the retired FIPS 74, "Federal Information Processing Standards Publication 1981 Guidelines for Implementing and Using the NBS Data Encryption Standard." This document is so old that it even refers to NIST as the National Bureau of Standards (NBS), a name that hasn't been used since 1988. FIPS 74 was withdrawn in 2005, so this technique should probably be considered obsolete. Here's how it works.

Suppose that we want to encrypt a credit card number that has 16 digits. The FIPS 74 technique encrypts one digit at a time. To do this it creates four bits that are XORed with the four bits that represent a digit. These four bits come from the lowest four bits of the output of a DES encryption. If the result of the XOR operation isn't a valid digit, then the next lowest four bits of the DES output are tried, etc. If all 16 of the four-bit values in the DES output don't give a valid digit, then the binary value 1001 is XORed with the plaintext input to get the ciphertext output. A new output of a DES encryption is used for each digit. Here's a diagram that shows how this works. This can easily be extended to more than digits. FIPS 74 describes techniques for encrypting both alphanumerics and arbitrary alphabets.

  

This technique seems to be fairly slow. Each digit it will take an average of (10/16)(1) + (6/16)(10/16)(2) + (6/16)²(10/16)(3) + ... + (6/16)¹⁴(10/16)(15) + (6/16)¹⁵(16) = 1.6 DES encryptions to encrypt, so that it will take an average of 25.6 DES encryptions to encrypt a single 16-digit credit card number.

Curiously, it looks like NIST hasn't defined a similar way to do format-preserving encryption with AES. Maybe there's really no need to do that because there exist other techniques that have strong proofs of security. The fact that a format-preserving encryption technique was included in FIPS 74 makes me think that there was an interest in the technology well before the PCI DSS increased the level of interest in encryption. Is the FIPS 74 technique used anywhere these days?

R. C. Matheson gets a certificate

Web site.

Find page.

Click "Login."

Enter Username.

Enter Password.

Click "OK."

Click "certificates."

Click "request certificate."

Click "request."

Click "request."

Yes, again.

Doesn't work.

IE8 problem.

Try Firefox.

Repeat steps.

First 10.

It works.

Click "next."

Select email.

Click "next."

Click "next."

Another duplicate.

Click "accept."

Click "next."

Click "finish."

Wait.

Check email.

Open email.

Click link.

Click "OK."

Certificate installed.

Now what?

Gentry's homomorphic encryption

There's been a lot of talk lately about Craig Gentry's new homomorphic encryption scheme that’s based on lattice cryptography. The discussion that I've heard has been essentially one of two types. Some people are saying, "Wow, that's incredibly cool. And his proof is cool too." Others are saying, "What the heck is homomorphic encryption, anyway?" What follows is for the people who are saying the latter of these two.

The term "homomorphic" is used in homomorphic encryption because of the connection to a homomorphism, which is a function that roughly lets us switch the order of doing a mathematical operation and evaluating the function.

For an example of this, consider the function f(x) = e^x_. This function has the property that e^x+y = e^xe^y, or that f(x + y) = f(x) * f(y), which means that we can roughly switch the order of implementing the mathematical operations and applying the function. In the first case, we apply the operation + first and then the function f, and that's equal to what we get from applying the function f first and then the operation *. A function that behaves that way is called a "homomorphism."

Now suppose that f is an encryption function that happens to be a homomorphism. If that's the case, you could implement an operation on plaintext by doing a different operation on ciphertext, and you could even do this without having to decrypt the ciphertext. From the point of view of most uses, this is a bad property because it lets an adversary change a ciphertext into one that decrypts into an entirely different plaintext, but that doesn't stop such functions from being inherently interesting.

If we have an RSA public key (n,e) and encrypt a message m by calculating c(m) = m^e mod n, then we have that c(xy) = (xy)^e = x^ey^e = c(x)c(y). This means that we can switch the order of encryption and multiplication and get the same result, so RSA is a form of homomorphic encryption. We can take advantage of this fact, for example, by changing a ciphertext c(x) into one that decrypts into 2x by multiplying c(x) by c(2), and we can do this without decrypting the ciphertext c(x).

On the other hand, this only works for multiplication and doesn't work for addition. For RSA encryption, we don't have that c(x + y) = c(x) + c(y). If we had that, we could do even more tricks with ciphertext and have something useful happen to the plaintext.

The reason that Gentry's work is interesting is that it lets you do just that. It's homomorphic for both addition and multiplication. His scheme lets you do an arbitrary number of additions and multiplications, with the only requirement being that a limit on the number of multiplications needs to be fixed when you generate a user's public key.

It also appears that Gentry's scheme is totally impractical. This means that we won't be seeing a start-up that makes products based on Gentry's homomorphic encryption scheme any time soon, but that shouldn't stop us from admiring the elegance of his invention.

NIST gets in the Cloud Computing game

It looks like NIST is now getting interested in cloud computing. I found it somewhat interesting that the information on their web site about Cloud Computing is provided by their Computer Security Division, possibly indicating that security is one of the most important issues that need to be addressed before Cloud Computing can become more accepted.

Apparently, it's even tricky for NIST to sort through some of the claims that people make about Cloud Computing. According to the NIST's "Presentation on Effectively and Securely Using the Cloud Computing Paradigm v20", for example, there's a fairly wide range of estimates for the potential cost savings that Cloud Computing can allow: from 18 percent to 90 percent. That's a fairly big range.

Something that saves you 90 percent is certainly a much bigger deal than something that can save you 18 percent. If I had to bet, I'd say that the estimates of 90 percent are way off, and the real savings that are possible are much lower.

It could be worse

Reading academic papers on cryptography is hard. It's not like reading music, where you can sit down at the piano and hack your way through a new piece of music. Sure, you'll make lots of mistakes your first time through, and it may sound so bad that you want to do it well away from other people, but you'll get through it fairly quickly. Reading papers on cryptography is much worse, at least it is for me. Getting through a paper and understanding what it really says usually takes me at least a few days. Maybe more if I don't get a good night's sleep or drink enough coffee.

Some papers take much longer than that to understand. Back when Andrew Wiles proved Fermat's Last Theorem, I realized that I'd never understand Wiles' proof, so I tried something much less ambition: to read and understand a paper that explained exactly why what Wiles proved, the Taniyama-Shimura conjecture for semistable elliptic curves, implies that Fermat's Last Theorem is true. Even that turned out to be too hard, and I eventually gave up on it.

I recently learned that it's not just papers on cryptography that are hard to understand, but papers on other topics may hard to understand for an entirely different reason, and that's because they're poorly written. There are apparently so many poorly-written academic papers that the editors of Philosophy and Literature felt the need to run a bad writing contest that showcased some of the worst academic writing around.  Here are some of the past winners of this contest:

The move from a structuralist account in which capital is understood to structure social relations in relatively homologous ways to a view of hegemony in which power relations are subject to repetition, convergence, and rearticulation brought the question of temporality into the thinking of structure, and marked a shift from a form of Althusserian theory that takes structural totalities as theoretical objects to one in which the insights into the contingent possibility of structure inaugurate a renewed conception of hegemony as bound up with the contingent sites and strategies of the rearticulation of power.

Judith Butler, "Further Reflections on the Conversations of Our Time,” Diacritics

Total presence breaks on the univocal predication of the exterior absolute the absolute existent(of that of which it is not possible to univocally predicate an outside, while the equivocal predication of the outside of the absolute exterior is possible of that of which the reality so predicated is not the reality, viz., of the dark/of the self, the identity of which is not outside the absolute identity of the outside, which is to say that the equivocal predication of identity is possible of the self-identity which is not identity, while identity is univocally predicated of the limit to the darkness, of the limit of the reality of the self). This is the real exteriority of the absolute outside: the reality of the absolutely unconditioned absolute outside univocally predicated of the dark: the light univocally predicated of the darkness: the shining of the light univocally predicated of the limit of the darkness: actuality univocally predicated of the other of self-identity: existence univocally predicated of the absolutely unconditioned other of the self. The precision of the shining of the light breaking the dark is the other-identity of the light. The precision of the absolutely minimum transcendence of the dark is the light itself/the absolutely unconditioned exteriority of existence for the first time/the absolutely facial identity of existence/the proportion of the new creation sans depth/the light itself ex nihilo: the dark itself univocally identified, i.e., not self-identity identity itself equivocally, not the dark itself equivocally, in “self-alienation,” not “self-identity, itself in self-alienation” “released” in and by “otherness,” and “actual other,” “itself,” not the abysmal inversion of the light, the reality of the darkness equivocally, absolute identity equivocally predicated of the self/selfhood equivocally predicated of the dark (the reality of this darkness the other-self-covering of identity which is the identification person-self).

D.G. Leahy, Foundation: Matter the Body Itself

So I suppose that it could be worse. Instead of having to read and understand papers on cryptography, I could have to read and understand papers in some other field. Based on some of the entries into Philosophy and Literature's bad writing contest, I may be fairly lucky.

Security through simplicity

If you're trying to estimate the security provided by a particular key management technique, you can essentially ignore the chances of any cryptographic algorithm being defeated. The chances of a peer-reviewed algorithm being weak, particularly when it has a rigorous proof of security is extremely small. On the other hand, the chances of a weakness in some component of a key management system is significant. It's very hard to implement and keep a secure configuration, and even if you can do this, you'll still exposed to bugs in the software and hardware that implements the key management system. You can formalize this if you really want to by writing an expression for the security of a system in terms of the security of each of its components, but even without explicitly writing that down, it should be fairly clear that simpler systems are inherently more secure than more complex ones.

Using this principle, let's look at two architectures and see which is more secure: one that implements X.509-based PKI or one that implements identity-based encryption. Here's a diagram that shows the components of a PKI system and how they interact when Alice sends an encrypted message to Bob. For this system to operate securely, each of its components needs to operate securely.

  

Now here's a diagram that shows the components of an IBE system and how they interact. Alice, who wants to send a message to Bob, just needs to get a set of public parameters from a secure key server that's usually called the private key generator, or PKG. Once she has these, she can encrypt messages to Bob. She can actually encrypt them to anyone else also, so she actually only needs to do that once. Once Bob receives Alice's message, he gets the key needed to decrypt it from the PKG. You don't need to do key look-up with IBE, so there's no component that acts like the LDAP directory does for a PKI, and because IBE keys are calculated as needed, there's also no need for a component that acts like a key archive server.

 

This system has only one-fourth the number of components of a system that implements PKI, which means that it has fewer ways to fail, which means that's it's more secure. Simpler is definitely better.

SSNs versus CCNs

There's lots of talk these days about securing credit card numbers. As I've mentioned before, people should have more of an interest in keeping information like their Social Security number protected. If your credit card number is compromised you can always have the old card canceled and a new one issued to take its place. With your Social Security number, however, you can't do that. Once it's compromised, there's no way to get it back.

It turns out that there's another big difference between credit card numbers and Social Security numbers, and that concerns how often they're exposed in data breaches. According to the information in the OSF's database of data breaches, incidents that expose a Social Security number are far more common than data breaches that expose credit card numbers. The last time I looked at the data in this database, for each incident that exposed credit card numbers there were almost seven incidents that exposed Social Security numbers.

Maybe the government should start a program like the PCI DSS to ensure that anyone handling Social Security numbers needs to have some basic security mechanisms in place.

The 2010 Key Management Summit

The web site for the 2010 IEEE Key Management Summit is now up. This event will be held on May 4-5, 2010 in Lake Tahoe, Nevada, and will be collocated with the IEEE Symposium on Mass Storage  Systems and Technologies.

We're already looking for speakers for this event and hope to finalize the list in roughly November of this year. So if you're interested in presenting at this event, it's not too early to send in your submissions.

More Bayesian thoughts

Encryption isn’t as widely used as it could be, and we might be able to understand this from the point of view of Bayesian statistics. Here’s why.

Much of the negative feelings that people have about encryption can probably be explained by the bad reputation that encryption has, and this reputation is probably justified. Many people who used some of the encryption products that were available back in the dot-com era are probably still suffering from the trauma that using encryption caused them. Older encryption products were hard to use, which made them expensive to support.

Even security specialists couldn’t use some of the early encryption products. When I worked at one of those dot-com era companies that made those early encryption products, I remember being stunned by a demo of an application that we had developed to let users authenticate to a server using the WTLS protocol. It was terrible, and this was from the point of view of a person who thought that using X.509-based client certificates was easy.

Many people suffered through using the early encryption products, and they’ve probably developed a significant bias against using encryption because of this. This is perfectly understandable. From a Bayesian point of view, they’ve built a knowledge base that tells them that encryption is hard and expensive, and this will affect how much they believe that newer products are actually easier to use.

Suppose that you tell a person who used older encryption technologies that the newer ones are much easier to use. If they're using Bayesian reasoning, they probably won't believe you, and this is because of what they're really estimating when you tell them this.

Let E represent how much someone believes that encryption is actually easy to use, N represent the claim that newer encryption technologies are easier to use than earlier ones, and K represent experience with the older technologies. If people are using Bayesian reasoning, instead estimating P(E|N), they're really estimating P(E|K∩N). If you’re really motivated, you can work through calculating P(E|K∩N), much like we did in an earlier post, and if you do this you’ll find that we can’t expect people to believe that the newer technologies are actually usable.

The problem is that they are.

Encryption has become much easier to use in the past five years or so, and it’s now feasible to use in many situations where it wasn’t practical at all in the past. That means that there’s now a solid business case for its use, even though people may not actually believe it. After all, the people who are making decisions about using encryption today are the same people who had to suffer through using the bad implementations of it that we had in the dot-com era. And because their experience has told them that encryption is hard and expensive, we can expect them to not believe that newer technologies are really any better.

One way to address this problem may be for researchers to look at the newer technologies and try to measure their usability. The famous paper “Why Johnny Can’t Encrypt” was followed by “Why Johnny Still Can’t Encrypt” a few years later, but the later work didn’t look at the newer technologies. Instead, it looked at how much the same technology used in the earlier study had improved. A more useful study might look at products like Voltage’s SecureMail, which is much easier to use than the previous generation of products.

The participants in the study that was described in “Why Johnny Can’t Encrypt” had to do some fairly low-level work with their keys. A user of SecureMail, on the other hand, doesn’t need to worry about those details at all. If they can click on the “Send Secure” button instead of the “Send” button in their email client then they can send encrypted messages. I can’t believe that any study would find that particular task too difficult for most people to do.

The problem may be finding a way to get people to believe that it’s really that simple. If they’re using Bayesian reasoning, however, they might not even believe it after they’re shown it. How do you work around that?

How to stop some data breaches

I just read an interesting paper, "Nobody Sells Gold for the Price of Silver: Dishonesty, Uncertainty and the Underground Economy," by Cormac Herley and Dinei Florêncio of Microsoft Research. Herley and Florêncio describe an interesting way to fight data breaches, and that's by contaminating the data that's available for sale by cyber-criminals. The reason that what they propose would probably reduce data breaches is based on the work that won George Akerlof the Nobel Prize in Economics in 1991.

Akerlof's insight was that if buyers can't tell the quality of what they're buying, then markets can fail. His favorite example of this is a hypothetical market for used cars.

Suppose that used cars are worth $10,000 if they're in good condition, but half of them require $1,000 in repairs and that buyers can't tell which cars are which. If this is the case, then a rational buyer would only pay $9,500 (= 0.5 * $10,000 + 0.5 * $9,000) for a used car. But at this price, the owners of the high-quality cars won't sell, because theirs are worth $10,000. This leaves only the lemons on the market, which will further depress the price of used cars, and will lead to the failure of the market for used cars unless buyers have some way to distinguish the good cars from the lemons.

Apparently, there are also quality uncertainty issues in the market for stolen credit card numbers, and this leads to a way to make this market fail. If we can add enough bogus credit card numbers into the market for stolen credit card numbers, if Akerlof's model is right, this will lead to a downward spiral in how much cyber-criminals can get stolen credit card numbers. If we can reduce this low enough, it will no longer be worth their effort to sell stolen credit card numbers and the market will essentially disappear. So flooding the underground market with bogus credit card numbers might be a way to stop some data breaches, in particular, the ones that are caused by hackers actively compromising a system to steal credit card numbers. 

That's an interesting idea, but I doubt that we'll see credit card companies doing it any time soon.

Signed malware

Associating a digital signature with software can be useful because it gives you a reasonable assurance of the source of the code. But because it’s easy to misuse a code signing certificate by using it to sign malicious code, there’s absolutely no reason to believe that all signed code isn’t malicious in some way. Exactly how common is signed malware?

The Microsoft Security Intelligence Report gives lots of interesting statistics about malware, and version 5 of this document, the one that covered January through June 2008, had some information about signed malware. Here’s how the Microsoft report described what they saw:

In the first six months of 2008, the MMPC received reports of about 22 million instances of distinct malware files, of which about 173,000 were distinct malware files with code signatures. Of this malware with code signatures, about 38,000 had signatures that were not valid for signing code, so approximately 135,000 validly signed malware files were reported to Microsoft. In total, approximately 0.6 percent of detected malware was validly signed.

That’s useful information, but what would be even more useful is an estimate of the probability of having malware given that software has a valid digital signature. That information isn’t available in the Microsoft report.

Security as entropy

It turns out that there may be a connection between security and entropy. Here’s why this is the case.

Let’s assume two things. First, let’s assume that security is a function S of the exploitability of the technologies that are used to implement it, where exploitability is some sort of probability measure P. Next, let’s assume that security follows these general rules:

1. The security provided by two technologies when they’re both used is greater or equal to the security of each of the components when they’re used by themselves
2. If two technologies are independent then the security provided by the two technologies when they’re used together is equal to the sum of the security provided by each of the technologies
3. The security provided by any technology is non-negative

If security follows these rules, it turns out that it has to be a function that looks like S(P) = -log(P). We can make the base of the logarithms anything that we want, but it has to be of this general form.

Now suppose that a particular technology X can perform n different security functions with probabilities p₁,p₂,…,p_n. If this is the case, then the average or expected level of security provided the technology X is 

which is just another way of writing entropy.

Some people that I've mentioned this connection to tell me that it's is obvious. Others don't think that it's that obvious at all. Just like you can think about Shannon entropy as what you don't know about information, you might be able to think of security as what adversaries don't know about your information, although that might be going a bit too far.

I doubt that there's anything profound about this observation, but because of this connection to entropy, some of the things that we observe about data breaches may turn out to not be coincidences. There are some things that seem to make sense if we think of them as coming from situations where entropy is maximized, for example. Maybe that'll be the topic of a future post.

A Bayesian approach to understanding tokenization

I had an interesting discussion last week about why most security experts don’t believe them when tokenization vendors claim that their technology is more secure than encryption. It seems that understanding this is good example of an application of Bayes’ theorem. Here’s why.

Let E represent the belief that encryption is the most secure way to protect sensitive information. Let K represents the knowledge that we have of the effectiveness of security technologies and T represent the belief that tokenization is more secure than encryption.

What we’re interested in is the probability that encryption is the most secure way to protect sensitive information given the claim made by tokenization vendors and our prior understanding of security technologies: P(E|T∩K). We can use Bayes’ theorem to write this as

P(E|T∩K) = P(E|K) P(T|E∩K) / P(T∩K)

= P(E|K) P(T|E∩K) / (P(E|K) P(T|E∩K) + P(NOT(E))|K) P(T|NOT(E)∩K))

Let’s assume that before we hear any claims about the security of tokenization, we’re fairly confident that encryption is the best way to protect sensitive information, so that P(E|K) = 0.99. If we don’t believe that encryption is the most secure way to protect sensitive information then it's reasonable to assume that we might believe that tokenization is a good alternative. To reflect this let’s assume that P(T|NOT(E)∩K)) = 0.9. On the other hand, you’d be hard pressed to find a single cryptographer who agrees that tokenization is more secure that encryption, so it’s probably the case that we should doubt the claim that tokenization is more secure than encryption. To reflect this, let’s assume that P(T|E∩K) = 0.1.

With these values we can now calculate P(E|T∩K) as

P(E|T∩K) = (0.99)(0.1) / ((0.99)(0.1) + (0.01)(0.9)) = 0.9167

so that Bayes’ theorem tells us that there’s no reason to assume that the claims that tokenization is more secure than encryption should really change our belief that encryption is the best way to protect sensitive information.