Superconductor

Weak cipher suites with EV certificates

We had an interesting discussion of EV certificates in the X9 meeting last week. Apparently, EV certificates guarantee that some non-trivial means of authentication was used to authenticate the entity requesting an EV certificate, but there are minimal requirements other than that authentication. In particular, some people at the X9F4 meeting were a bit concerned by the fact that you can apparently use an EV certificate with an extremely weak cipher suite, which means that it's possible to have a connection to a server that uses an EV certificate yet creates a connection that's extremely easy for a hacker to beat.

The administrator of the server that uses an EV certificate can always configure his server to not allow weak cipher suites, and most of them probably do, but the people at the X9F4 meeting thought that the use of strong cipher suites really ought to be required with EV certificates.

The right stuff

I recently read an article in The Washington Post about how the US government is having a hard time finding qualified information security people. One of their proposed solutions is to take existing government employees and retrain them to make them information security specialists. This is almost certainly a bad idea.

When I worked for the government, we had a similar staffing problem at the end of the Cold War. At that time, we had lots of Russian linguists but not enough people in technical fields. To solve this problem, the government decided to to retrain the Russian linguists into engineers and other technical jobs. It didn't work very well.

Imagine you're a government employee who has been translating Russian for maybe 10 or 20 years, and you're suddenly told that you need to retrain to become an engineer. You probably became a Russian translator because of your particular skills and aptitudes, and those skills and aptitudes are very different from those needed to succeed as an engineer. You may have the right stuff for a particular job, but that right stuff doesn't necessarily translate into the right stuff for another job.

I taught some of the classes that were supposed to do this retraining, and it didn't seem to me that this effort was going to work very well. This really shouldn't have surprised anyone.

Your typical cryptographer, for example, has probably spent several years studying the math that you need to understand the foundations of cryptography. In the government, our rule of thumb was that it took about three years on the job before a person with that background could make significant contributions on the job. This is definitely not the sort of training that you can fit into a class or two, and it's definitely not the sort of thing that you can easily pass on to mid-career Russian linguists who are stressed about losing their job if they can't learn material for which they have absolutely no aptitude.

Let's hope that the government remembers how well the previous attempt worked, and doesn't try it again today. Our attempt at cross-training people didn't work very well at the end of the Cold War, and I'd expect a similar attempt to fail today.

Making change

My wife went out for pizza last week and came back with an incredible story. She ordered two pizzas on-line and went to the store to pick them up. When she arrived at the pizza store their computer was down. When she paid with cash, she was surprised to see the cashier pull out a calculator that she used to calculate the change due from my wife's purchase. The cashier explained that they had to use a calculator to figure out how much change to give a customer and that they would get fired if they were caught making change without the use of the calculator.

I'd guess that the pizza store didn't just make the use of calculators mandatory for no reason. They almost certainly did this because their employees couldn't do it accurately without a calculator.

It's somewhat popular these days to criticize the exit exam that California high school students have to pass to graduate. Opponents like to say that it forces teachers to teach just the material that's covered on the test, and that this reduces the overall quality of education. Supporters of the exam maintain that it's just testing basic skills and that its requirements are quite reasonable. If pizza stores have to require their employees to use calculators to make change accurately, I'd guess that the exit exam isn't testing enough.

The fact that people can pass the exit exam and still can't make change accurately may account for the following joke:

Question: What is 2+2?

Answer: A question on the California high-school exit exam

Another example of rational points on an elliptic curve

Here's another example of finding rational points of finite order on an elliptic curve.

Suppose that we have the elliptic curve y² = x³ - 2x + 1. In this case we have that D = 5, so that the possibilities for the y-coordinate of a rational point of finite order are limited to 0, ±1 by the Nagell-Lutz theorem. A quick check of these possibilities shows that we have the following points:

P₁ = (1,0)

P₂ = (0,1)

P₃ = (0,-1)

Here's what this looks like:

These points form this subgroup of the points on the curve:

Rational points on y² = x³ - 2x + 1

+	O	P1	P2	P3
O	O	P1	P2	P3
P1	P1	O	P3	P2
P2	P2	P3	P1	O
P3	P3	P2	O	P1

We can also think of the elliptic curve y² = x³ - 2x + 1 as being parameterized by the Weierstrass ℘-function with periods ω₁ and ω₂ where we have approximately

ω₁ = -2.01891 i

and

ω₂ = 2.96882

All of the points on y² = x³ - 2x + 1 that have the property 4P = O come from the complex numbers shown here: 

 
Of these 16 points, these are the ones that we get the subgroup of rational points of finite order from (z₁ corresponds to P₁, etc., and z₀ corresponds to O):

Sign up now for the 2010 Key Management Summit

It looks like the agenda for the 2010 Key Management Summit is all set. This year's event will include an interesting range of presentations: talks by industry analysts, vendors, users of key management technology, and even a talk or two about cutting-edge research. We're also considering having some time set aside for impromptu presentations.

Suppose that you're sitting through one of the talks and what the speaker says gives you an idea that the rest of us would be interested to hear. The intent is to have some time allocated to hear these ideas - probably something that can be summarized in a slide or two.

I'm not sure how well that will actually work in practice, but it sounds like an interesting idea. I hope that we'll get a chance to try it in May.

It's easy to become famous

Intrigued by the possibility of becoming famous that I mentioned in the last post, I looked more closely at the email that invited me to get listed in some sort of prestigious publication and found a link that had my name in the URL. Once I saw this, I wondered how easy it would be for someone else to become famous. To test this, I removed my name from the URL and put in the name of one of my wife's stuffed animals.

Apparently Putsi Fischotter is also famous enough to get his name listed.

 

Maybe if I send these guys a picture of a stuffed otter dramatically staring off into the distance they'll add that image to their web site.

I'm famous!

I recently received another one of those annoying emails that tell you that you're so famous that some publisher would like to include you in a book that lists other famous people and their accomplishments.

Here's what these guys said:

It is my honor to inform you that as of January 22, 2010 you are being considered for inclusion in our forethcoming [sic] edition of the 2010 directory representing the WHO'S WHO of Worldclass [sic] Professionals.

Our alliance is recognized by talented individuals who hold knowledge and experience in a particular industry, demonstrate a commitment to excellence, and seek career advancement or enhancement.

On behalf of the CEO and our esteemed staff, we wish you continued success.

I'm not sure how these emails manage to get past our spam filter, but they do it fairly often. I must get one of these at least once per week. I get them so often that I'm now convinced that the only criterion for getting listed in one of these books is having a valid email address. I'm not sure that counts as holding knowledge and experience in a particular industry. It's hard to see how that demonstrates commitment to excellence or seeking career advancement or enhancement, either.

I have to wonder if other talented individuals like sales@voltage.com and marketing@voltage.com are already listed in one of these fine publications.

A discussion with a lobbyist

I recently had an interesting discussion with a lobbyist, one of those people who hang around Washington and try to influence laws on behalf of whoever's paying them. I met this particular lobbyist at a standards meeting, and we had an interesting discussion about the behavior of politicians. This particular lobbyist told me that he found that most politicians are actually fairly reasonable most of the time and try to get reasonable laws passed and are generally open to reasonable compromises to get that to happen.

At least that's until an issue starts making headlines. At that point, everything changes. That's when people start voting along party lines and the chances for reasonable compromises seem to go out the window.

The discussion that I had was actually about the lobbyist's efforts to influence Congress to pass laws changing how credit card companies do business in the US, but his comments seem applicable to more situations that just that one. Like the stuff that's making the headlines these days.

Why use projective coordinates?

Projective coordinates are often used to represent points on an elliptic curve. This is useful for two reasons. It provides an easy way to represent the point O on an elliptic curve using the same coordinate system that all of the other points use. It also may be more efficient to do operations on projective coordinates than on the usual, or affine, coordinates.

Projective coordinates represent ratios of numbers instead of just numbers. So the number 4 could be represented as either 4 = 4/1 or as 4 = 8/2, which we would write as (4,1) and (8,2) in projective coordinates. Clearly, there's not a unique way to represent affine points in projective coordinates.

To encode the point at infinity, we just set the last coordinate to 0, using division of anything by 0 to indicate infinity.

If we have to numbers x₁ and x₂ we can write them in projective coordinates as

x₁ = X₁/Z₁

or

(X₁,Z₁)

and

x₂ = X₂/Z₂

or

(X₂,Z₂)

If we want to calculate x₁/x₂ we can use the projective coordinates to find that

x₁/x₂ = (X₁/Z₁) / (X₂/Z₂)

= X₁Z₂ / X₂Z₁

which we can write as

(X₁Z₂,X₂Z₁)

in projective coordinates.

Note that this means that we've actually calculated x₁/x₂ without using any division operations at all. The tradeoff is that it takes more operations to implement projective operations. In this example, we've calculated x₁/x₂ without using any division operations, but at the cost of using two multiplications instead of one division. But if division operations are significantly more expensive that other operations, this can be a useful way to avoid using the more expensive operation.

There are actually more than one way to define projective coordinates in a useful way for points on elliptic curves. The most common way writes an affine point

P = (x,y)

as the projective point

P' = (X,Y,Z)

where

x = X/Z

and

y = Y/Z

This form of projective coordinates also has the advantage that division operations on coordinates can be implemented without using any division operations. Whether or not it's actually preferable to using affine coordinates depends on exactly how fast additions, subtractions, multiplications and divisions are on a particular platform.

Warning message message message message message

I recently looked into getting a copy of the Sage open-source math software. I was curious about how it compared to the software that I'm used to, like Mathematica or Maple. Like you seem to get with lots of open-source software, this wasn't as simple as I'd hoped. I first had to download Sun's VirtualBox software. When I installed this, I was surprised to get the following warning message:

Seeing this once was somewhat educational. Ah, this software hasn't been fully tested as being compatible with Windows.

I Continued Anyway and was surprised to see the same warning message FOUR additional times. I'm not sure exactly when it happened, but this message stopped being useful after a while. Probably after the second time that I saw it. There might be a good a reason why I had to see the same warning FIVE times, but it's not obvious to me exactly why that is.

I never did get a chance to try Sage. This might explain why:

 
  
 

Information security in two sentences

In privacy and computer security, real information is too hard to find. Most people don't know what's really going on, and many people who do know aren't telling.

EFF, Preface to Cracking DES, 1998

It hasn't changed much since 1998, has it?

National Cyber Leap Year follow-up

Last year, the US government held the National Cyber Leap Year Summit. Lots of smart people got together and made a series of recommendations to the government. You can read their recommendations here. 

This report came out last September. Some of its recommendations were things like this:

6.8 Idea - Removing Barriers to Entry for Crypto Products into Federal Use

Streamline and expedite the approval process for Federal use of new security technologies.

6.8.1 Description

Many commercial security technologies are unavailable for Federal use even though they are well accepted and widely deployed in the private sector. These technologies often allow dramatic cost savings and efficiency gains over older technologies, but Federal agencies are unable to use them because the technologies have not received the necessary certifications and approvals. In some cases, the existence of rigorous, formal proofs of security should eliminate the need for the long certification and review process and allow Federal agencies to receive the same benefits that the private sector is now realizing. A decade or more is too long for Federal agencies to wait to realize the benefits of new security technologies. Let's find a way to get new technologies used more rapidly.

6.8.2 Inertia

This has not been done yet because the Federal agencies involved in approving new security technologies have relied on the "wait and see if it's secure" model so far. This approach usually determines which technologies are sound and which ones are not, but takes many years and leaves Federal agencies unable to use the innovative security technologies that are being invented today.

6.8.3 Progress

Provable security has made the "wait and see" model unnecessary in many cases. If there is a peer-reviewed formal proof of the security of a technology, that should be enough to get approval for Federal use. If the proof is correct then the technology is secure. Why wait ten years or more if that's the case?

6.8.4 Action Plan

NIST should determine a way to quickly approve provably-secure technologies for Federal use and should review existing regulations and identify ways to allow provably secure technologies within them. This should involve, as a minimum, granting a blanket IATO to new encryption technologies with peer-reviewed proofs of security, and adding provably-secure public-key encryption technologies to the list of techniques that are allowed by FIPS 140-2. In the long run, standards and policies should be changed to allow the rapid adoption of new technologies that are provably secure.

6.8.5 Jumpstart Plan

Within 90 days, NIST should define and implement a way to approve provably secure technologies for Federal use. Within 180 days, a pilot of one of these technologies should be started at a Federal agency.

I haven't heard of any progress in the government on this particular issue. I'm fairly sure that NIST hasn't developed a plan to approve provably-secure technologies for government use and that no government pilot projects of provably-secure technologies have started.

Has there been progress in any of the other areas that the summit participants recommended?

You are here

When I recently logged in to the ISSA web site, I was surprised to see that the web site apparently thinks that I'm in rural Libya somewhere. Here's what its map showed for my location:

Based on this, the 10 closest ISSA chapters to me are Italy, Abuja, Egypt, Spain, Switzerland, Istanbul, France, Romania, Israel and Lagos. Voltage often supplies speakers for ISSA meetings, but I don't think that we've sent anyone to any of these locations yet, even though they're apparently fairly close to us.

I didn't know that there are actually two chapters in Nigeria (Abuja and Lagos). Maybe keeping one step ahead of all of the spammers requires lots of security professionals. Maybe there's a different reason. The population of Nigeria is roughly 150 million, or about half the size of the US, so there must be lots of businesses there that need information security people.

The discriminant of an elliptic curve

 

If you're a fan of using high-powered techniques to solve easy problems, you can replace the first step with this.

Pokemon combinatorics

Collectable card games are incredibly popular. The cards for these games are typically sold in packages of several cards. The manufacturers print several sheets of cards, and include cards from the different sheets in these packages with different frequencies. They might include four cards from sheet A, two cards from sheet B and a single card from sheet C, calling the cards from sheet A “common,” the ones from sheet B “uncommon” and the cards from sheet C “rare.” Your ability to complete a collection of the entire set of cards is clearly limited by your ability to collect all of the rare cards.

How many packages of cards can you expect to have to buy before you complete a set?

A solution to this problem was described by Paul Erdős and Alfréd Rényi in 1961. Here’s roughly how their solution goes.

Suppose that we already have k different rare cards out of a total set of n possible cards. The next time we buy a pack of cards the probability to not get a new rare card is k/n so the probability that we need to buy exactly p packs of cards to get another new rare card is

(k/n)^p-1 (1 - k/n)

so the expected number of packs of cards that we’ll need to buy to a new rare card is

Σ_p≥1 (k/n)^p-1 (1 - k/n) p = 1 / (1 - k/n)

= n / ( n - k)

So the expected number of packs of cards that we’ll need to buy to get all n rare cards is

Σ_k=0:n-1 n / ( n - k) = n/n + n/(n - 1) + … + n/2 + n/1

= n (1/n + 1/(n - 1) + … + 1/2 + 1/1)

= n H_n

So you should expect to buy packs equal to about H_n times the number of rare cards to get a complete set. If there are 50 rare cards in a set, for example, you should expect to buy about H₅₀ (approximately 4.5) times 50, or about 225 packs to get a complete set.

Here's how H_n grows as a function of n:

So for the number of rare cards in a typical set of collectable cards, a good rule of thumb is that you can expect to have to buy a number of packs of cards equal to between four and five times the number of rare cards to complete your set.

2009 reading

Last year I decided to keep track of the books that I read using a Google documents spreadsheet. Looking at this list, it looks like a plurality of the books were actually mysteries, and all of these were actually from small specialty publisher Crippen and Landru. It looks like I read of total of 37 of their books last year. It was definitely time well spent.

Crippen and Landru specializes in printing or reprinting classic detective stories. They seem to emphasize the type of story in which the reader is shown all of the relevant clues before the story's protagonist solves the puzzle. I prefer those type of detective stories over the stuff that's popular these days that I'd say is better classified as crime fiction instead of detective fiction.

In any event, Crippen and Landru publish two lines of limited edition books: Lost Classics and their regular line. The Lost Classics line reprints material that's fairly good, but not widely known. Examples of this are detective stories by Rafael Sabatini, who's better known for writing Captain Blood, or detective stories by western pulp writer Max Brand.

The regular line collects short stories from contemporary writers and its books include all sorts of interesting extra stuff. Some of the books include a page from the original typescripts for one of the stories in the book. Others include a short pamphlet that contains a story written by the author just for inclusion with the Crippen and Landru limited edition. All of them are signed by the author, and they'll probably be fairly valuable one day. Every one of these has been extremely good.

I still have quite a few Crippen and Landru books that are still unread. But since they're easily outnumbered by the stacks of unread books that don't contain any mysteries at all, there's no guarantee that my list of books read in 2010 will have the same bias.

What are they thinking?

There's a new social networking site that just made me think, "What are they thinking?!" This is Blippy, which apparently lets you broadcast to the entire world what you're buying. What worries me about this is the fact that the payments information that this service needs to use is fairly sensitive. How are they getting this? Is the process secure?

Here's what the Blippy web site says:

Blippy is a fun and easy way to see and discuss the things people are buying.

Automatically share your favorite purchases from iTunes, Amazon, Zappos, Visa, MasterCard, and more.

Yikes! Are they actually getting data about purchases from Visa and MasterCard? This is one (of many) social networking site that I definitely won't be signing up for.

Marginally interesting

 

Here's a picture of a notable page from a relatively unknown book. Apparently the right margin was just big enough to hold this:

Cubum autem in duos cubos, aut quadrato-quadratum in duos quadrato-quadratos, et generaliter nullam in infinitum ultra quadratum potestatem in duos eiusdem nominis fas est dividere cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet.

Factoring RSA-768

It was recently announced that a team of cryptographers (Thorsten Kleinjung and Kazumaro Aoki and Jens Franke and Arjen Lenstra and Emmanuel Thomé and Joppe Bos and Pierrick Gaudry and Alexander Kruppa and Peter Montgomery and Dag Arne Osvik and Herman te Riele and Andrey Timofeev and Paul Zimmermann) managed to factor a 768-bit RSA modulus. Although the technical work required to do this was very impressive, I'd say that this really wasn't a very newsworthy event.

According to the Implementation Guidance for FIPS 140-2, a 768-bit RSA key provides almost 70 bits of strength, so that it's about 13,700 times stronger than the 56-bit keys that the EFF DES Cracker was able to crack back in 1998. Taking into account the progress in technology over the past 12 years, it shouldn't be surprising to anyone that a massively-parallel network of computers can crack a 70-bit key today. It's so unsurprising that I have to wonder if funding projects like this one is really a good idea. Aren't there better uses for the resources?

Elliptic curves - connected or not

The graphs of some elliptic curves have one component like this one, the graph of y² = x³ + 1.

 

Others have two components like this one, the graph of y² = x³ – 2x + 1.

It turns out to be easy to tell these two cases apart. If the elliptic curve is defined by the equation y² = x³ + ax + b and we write D = -4 a³ - 27 b², then if D > 0 then the graph of the elliptic curve has two components and if D < 0 then the graph has one component. Here’s why.

D is the discriminant of the cubic f(x) = x³ + ax + b. So if we write

x₃ + ax + b = (x – x₁)(x – x₂)(x – x₃)

then we have that

D = (x₁ – x₂)²(x₁ – x₃)²(x₂ – x₃)²

Whether the graph of y² = f(x) has one or two components is determined by how many real roots f(x) has. If there is a single real root then the graph crosses the x-axis once and the graph has a single component, like we get with y² = x³ + 1. If there are three real roots then the graph then the graph crosses the x-axis three times and the graph has two disconnected components, like we get with y² = x³ – 2x + 1.

If f(x) has three real roots then D is clearly positive. What about the case of a single real root and a complex conjugate pair of roots?

Let’s write the roots of f(x) as

x₁ = a + bi

x₂ = a - bi

x₃ = c

where a, b and c are real. We can then write

D = (x₁ – x₂)²(x₁ – x₃)²(x₂ – x₃)²

= ((a + bi)– (a – bi))²(a + bi – c)²(a - bi – c)²

= (2bi)²((a - c) + bi)²((a – c) – bi)²

= -4b²((a - c)² + b²)

which is always negative, just like we wanted.

HR 2221 - the DATA Act

The House of Representatives passed HR 2221, the Data Accountability and Trust Act, last month, a bill that tries to set up a nation-wide, common way to handle data breaches. I really don't like the way the US government feels the need to make almost-clever names for laws that also create related acronyms (CAN-SPAM, DATA, etc.), but that doesn't make the content of HR 2221 any less interesting.

Here's how the House summarizes this bill:

Data Accountability and Trust Act - Requires the Federal Trade Commission ( FTC) to promulgate regulations requiring each person engaged in interstate commerce that owns or possesses electronic data containing personal information to establish security policies and procedures.

Authorizes the FTC to require a standard method or methods for destroying obsolete nonelectronic data.

Requires information brokers to submit their security policies to the FTC in conjunction with a security breach notification or on FTC request.

Requires the FTC to conduct or require an audit of security practices when information brokers are required to provide notification of such a breach.

Authorizes additional audits after a breach.

Requires information brokers to:

(1) establish procedures to verify the accuracy of information that identifies individuals;

(2) provide to individuals whose personal information it maintains a means to review it;

(3) place notice on the Internet instructing individuals how to request access to such information; and

(4) correct inaccurate information. Directs the FTC to require information brokers to establish measures which facilitate the auditing or retracing of access to, or transmissions of, electronic data containing personal information. Prohibits information brokers from obtaining or disclosing personal information by false pretenses (pretexting). Prescribes procedures for notification to the FTC and affected individuals of information security breaches.

Sets forth special notification requirements for breaches:

(1) by contractors who maintain or process electronic data containing personal information;

(2) involving telecommunications and computer services; and

(3) of health information.

Preempts state information security laws.

You can find the full text of the bill here.

Similar bills (HR 958, HR 3997, and HR 4127) have been introduced before, but none made it out of the House before this one.

There's a similar bill making its way through the Senate – S 1490, the Personal Data Privacy Act of 2009. Previous efforts in the Senate (S 495, S 1332 and S 1789) didn't go anywhere. It will be interesting to see how the House's attempt at addressing the problem of data breaches is received by the Senate.

Portable Code: Wait for the Bite

In my two previous posts (here and here), I said I don't like assertions or system calls when writing portable code. Looking back, I realize I may not have made something clear. So let me say it here.

Assertions and system calls are tools, sometimes powerful tools. They often make your life easier and sometimes are absolutely necessary to get the job done. However, they also cause problems in porting. So if you can avoid them, I think it's a great idea to avoid them. It may turn out that you use something and it does NOT come back to bite you. However, you don't know in advance what is going to bite you and what is not, so I think a programmer who has to write portable code should simply avoid these things if possible. It might make your job a little harder now, but it can save you a ton of misery later on.

Actually, there's one thing not completely correct in that last paragraph. I said, "... you don't know in advance what is going to bite you and what is not..." Sometimes you can know. Of course, sometimes the only way of knowing is because something on a previous project bit you, so for future projects you don't do that.

And I think that's why a lot of programmers don't believe me, they've never been bitten. Let me give you a couple stories.

Two companies ago, I learned that void * is not always a generic pointer. I also learned that not all compilers treat void * the same in all situations. Then at my next company, I was happy to discover that one of the coding standards said "Don't use void *." But one day I was working on a new project, let's call it project lion cub, and another programmer was using void *. I pointed out that our coding standards said not to and explained why one shouldn't use void * when writing portable code. The other programmer said I was being too paranoid and void * was a great tool.

When we tried to port lion cub to Solaris, it wouldn't. It turned out that the way Solaris and Windows treated void * was different enough to cause an incompatibility (in the way it was being used in the project). The other programmer spent a lot of time (weekend and night time) trying to reconcile the two but later on decided to just get rid of void * and use something else.

Then about two years later, this same programmer was working on another project. I noticed he was using void * in the same way, and suggested that's a bad idea. I reminded him of what happened in project lion cub. He remembered and decided not to use void *.

Here's another story. At my previous company I was working sort of as a consultant to another company who was writing crypto code. I noticed that the programmer was using enums. I pointed out that enums were not always portable. I told him why and described a situation in the past where someone who used enums found they didn't port and had a very difficult time getting rid of them while retaining backwards compatibility. This other programmer dismissed my concerns immediately.

Then he tried to port the code to another operating system. This new operating system treated enums just a little bit differently than his base OS, and the difference was just enough that his fastest course of action was to simply get rid of them.

In both those stories, someone had an opportunity to save themselves some headaches, but they didn't believe the advice. Once they were bitten, they did believe.

I think this is one thing that happens when I talk about portability. People just don't believe me until they see it with their own eyes. They have to be bitten to believe.

To be fair, there are some other reasons. First and foremost is that I'm almost certainly TOO paranoid when it comes to porting. I believe in a very safe route, sometimes safer than it needs to be. Second, many of the porting issues I have encountered 10 or 15 years ago, aren't issues anymore. And third, it is possible to use void * and enums in a portable way.

That third is an important issue. I say, "Don't use void * and enums." Someone else might say, "Go ahead and use void * and enums, but do the work necessary to make sure they are portable."

My philosophy is, "Write to a lowest common denominator, don't even tempt fate by using things that have been problematic in the past." Another philosophy might be, "Use all the tools at your disposal, just make sure you know how to use them in a portable fashion."

Either philosophy requires more work up front but has big payoffs later on. I still prefer my philosophy, after all, you can't really know what all the porting issues are until you try to port. So how can you know how to "use them in a portable fashion"? Or another argument is this: because you know you're going to have to do more work up front either way, why not choose the philosophy that's safer? Same work effort, safer porting.

What are you going to do when you run across a company that uses 16-bit chips or an old OS (maybe they've figured out a way to make a profit on outdated but extremely cheap technology) or a company that builds embedded devices or something else you can't predict? Maybe you've used the tools in a portable way, but your portable way covers Windows, Linux, Solaris, mainframe and most or all of the most common targets. But we just don't know what someone is going to come up with.

Is information security like preventive health care?

It's hard to find a good model for the cost-effectiveness of information security. Traditional risk management methodologies fail miserably because the unknowns that information security addresses typically can't be quantified like the unknowns that risk management methodologies are designed to handle. This means that the model of information security as an insurance policy really doesn't work very well.

What other models might work better? What about preventive health care? Preventive care is similar to information security in some ways. In both cases we spend money to prevent bad things from happening, and we hope that this will reduce the need to spend money after the bad things have happened.

According to the survey of medical literature done by Joshua Cohen, Peter Neumann and Milton Weinstein that was recently published in the prestigious New England Journal of Medicine, it turns out that most types of preventive care really aren't worth doing. Their analysis shows that, on average, it's really no better to spend money on preventive care than to treat existing conditions. This doesn't mean that all types of preventive care aren't worth doing. There are many cases where preventive care pays. Counseling adults to quit smoking is apparently an example of this, as is providing flu vaccines.

Cohen, Neumann and Weinstein also list cases where preventive care is beneficial but very expensive, things like "newborn screening for medium-chain acyl-coenzyme, a dehydrogenase deficiency." (Yes, I'll admit that I have absolutely no idea of what that means.)

In some cases, preventive care actually increases costs and worsens health. Treatments like "antibiotic prophylaxis (amoxicillin) for children with moderate cardiac lesions who are undergoing urinary catheterization" is apparently an example of this.

So if information security is like preventive health care, how well would popular information security technologies fare in a similar analysis? It's probably not too hard to come up with examples of technologies where it's no better to use a security technology than to just absorb the cost of not using the technology at all. Are there any obvious examples of technologies where you'll probably end up both spending more and getting worse security if you use them?