Financial Cryptography

What makes a Security Project?

Why is it that when you come across a good new thought, it is harder to deal with than an old, rehashed thought? I struggle with this all the time: E.g., blogs. my favourite ones are the writers that do original and new thinking. These guys nibble and munch at problems until they find answers. Then they bake solutions. These posts are so full of good stuff that I don't know where or how to respond. On the other hand, my unfavourite blogs are the ones that stick very clearly in the middle ground, express mildly polemic thoughts that a majority agree with and a minority already said, and seem to spend more time collecting and building popular support than anything useful.

Lots of good posts these days over at Gunnar's area, and I can't easily respond to them.

I see no evidence that [Sun] understand the need for writing secure code more so than Microsoft. In fact I see every evidence that Sun is several years behind Microsoft on software security. Let's do the list - Howard/Leblanc's work, threat modeling, software security patterns and practices, SDL, SecPal, BlueHat, OWASP guidance work and that is all before we get to identity stuff.

You won't see such an ... *opinion* from the popular fence sitters! Why is this? I think it is for several reasons. To say such a thing means you court disfavour with large companies, including the one you named, but also other companies who might realise you are likely to bark with more bite than other tame consultants.

Further, one has to think of the evidence to back up the opinion, and that's not always easy. I know because I tried to clarify this three years ago, while dealing with the question. When I sat and thought about why I thought some organisations weren't up to scratch, I had no easy answers. So I wrote down everything I could think of ... and then judged every organisation I knew on my list of metrics.

For once, then, I can respond to Gunnar, and in full wide-screen TV mode:

The Italian Job: highlights the gap between indirect and direct damage

If you've been following the story of the Internet and Information Security, by now you will have worked out that there are two common classes of damage that are done when data is breached: The direct damage to the individual victims and the scandal damage to the organisation victim when the media get hold of it. From the Economist:

Illustration by Peter Schrank

... Italians had learnt, to their varying dismay, amusement and fascination, that—without warning or consultation with the data-protection authority—the tax authorities had put all 38.5m tax returns for 2005 up on the internet. The site was promptly jammed by the volume of hits. Before being blacked out at the insistence of data protectors, vast amounts of data were downloaded, posted to other sites or, as eBay found, burned on to disks.

The uproar in families and workplaces caused by the revelation of people's incomes (or, rather, declared incomes) can only be guessed at. A society aristocrat, returning from St Tropez, found himself explaining to the media how he financed a gilded lifestyle on earnings of just €32,043 ($47,423). He said he had generous friends.

...Vincenzo Visco, who was responsible for stamping out tax dodging, said it promoted “transparency and democracy”. Since the 1970s, tax returns have been sent to town halls where they can be seen by the public (which is how incomes of public figures reach the media). Officials say blandly that they were merely following government guidelines to encourage the use of the internet as a means of communication.

The data-protection authority disagreed. On May 6th it ruled that releasing tax returns into cyberspace was “illicit”, and qualitatively different from making them available in paper form. It could lead to the preparation of lists containing falsified data and meant the information would remain available for longer than the 12 months fixed by law.

The affair may not end there. A prosecutor is investigating if the law has been broken. And a consumer association is seeking damages. It suggests €520 per taxpayer would be appropriate compensation for the unsolicited exposure.

An insight of the 'silver bullets' approach to the market is that these damages should be considered separately, not lumped together. The one that is the biggest cost will dominate the solution, and if the two damages suggest opposing solutions, the result may be at the expense of the weaker side.

What makes Information Security so difficult is that the public scandal part of the damage (the indirect component) is generally the greater damage. Hence, breaches have been classically hushed up, and the direct damages to the consumers are untreated. In this market, then, the driving force is avoiding the scandal, which not only means that direct damage to the consumer is ignored, it is likely made worse.

We then see more evidence of the (rare) wisdom of breach disclosure laws, even if, in this case, the breach was a disclosure by intention. The legal action mentioned above puts a number on the direct damage to the consumer victim. We may not agree with €520, but it's a number and a starting position that is only possible because the breach is fully out in the open.

Those then that oppose stronger breach laws, or wish to insert various weasel words such as "you're cool to keep it hush-hush if you encrypted the data with ROT13" should ask themselves this: is it reasonable to reduce the indirect damage of adverse publicity at the expense of making direct damages to the consumer even worse?

Lots of discussion, etc etc blah blah. My thought is this: we need to get ourselves to a point, as a society, where we do not turn the organisation into more of a secondary victim that it already is through its breach. We need to not make matters worse; we should work to remove the incentives to secrecy, rather than counterbalancing them with opposing and negative incentives such as heavy handed data protection regulators. If there is any vestige of professionalism in the industry, then this is one way to show it: let's close down the paparazzi school of infosec and encourage and reward companies for sharing their breaches in the open.

H2.2 KISS -- Keep the Interface Stupidly Simple

Here's another in my little list of hypothesies, this one from the set known as "Divide and Conquer." The delay in publishing them is partly the cost of preparing the HTML and partly that some of them really need a good editorial whipping. Today's is sparked by this comment made by Dan, at least as attributed by Jon:

... you can make a secure system either by making it so simple you know it's secure, or so complex that no one can find an exploit.
allegedly Dan Geer, as reported by Jon Callas.

#2.2 KISS

In the military, KISS stands for keep it simple, stupid because soldiers are dumb by design (it is very hard to be smart when being shot at). Crypto often borrows from the military, but we always need to change a bit. In this case, KISS stands for

Keep the Interface Stupidly Simple.

When you divide your protocol into parts, KISS tells you that even a programmer should find every part easy to understand. This is more than fortiutous, it is intentional, because the body programmer is your target audience. Remember that your hackers have to also understand all the other elements of good programming and systems building, so their attention span will be limited to around 1% of their knowledge space.

A good example of this is a block cipher. A smart programmer can take a paper definition of a secret-key cipher or a hash algorithm and code it up in a weekend, and know he has got it right.

Why is this? Three reasons:

• The interface is simple enough. There's a secret key, there's a block of input, and there's a block of output. Each is generally defined as a series of bits, 128 being common these days. What else is there to say?
• There is a set of numbers at the bottom of that paper description that provides test inputs and outputs. You can use those numbers to show basic correctness.
• The characteristic of cryptography algorithms is that they are designed to screw up fast and furiously. Wrong numbers will 'avalanche' through the internals and break everything. Which means, to your good fortune, you only need a very small amount of testing to show you got it very right.

An excellent protocol example of a simple interface is SSL. No matter what you think of the internals of the protocol or the security claims, the interface is designed to exactly mirror the interface to TCP. Hence the name, Secure Socket Layer. An inspired choice! The importance of this is primarily the easy understanding achieved by a large body of programmers who understand the metaphor of a stream.

USD reserve currency shift -- some numbers

Some figures on the decline of the dollar as reserve currency:

• emerging-market countries shrank their dollar holdings from 71% (1997) to 61% (2007), while growing their foreign exchange holdings over fourfold.
• the euro component of emerging market reserves grew from 19% (2000) to 28% (4th Q 2007).
• Japan's exports are now often invoiced in Yen: 34% (2001) to 40% (now). Back in 1971 it was almost all in dollars.
• dollars held outside the US: from 1.83% (2002) down to 1.22% (2006), as measured in percentage of world trade.

For the Americans, this is the maths behind the current too-good-too-bad economy in the USA. For the economists, it is interesting because the monetary tool is not helpful when all these dollars flood back unwanted. For the financial cryptographers, it's a great time to be in the currency business. For the gold community, it's their decade!

Note that we have predicted this for some time, but these are fundamental shifts and they move so slowly that any discussion is fraught until the numbers come in.

2003, 2004, 2006, 2006