Financial Cryptography

The Year of the Platypus - 2007 predicted

What is to happen in the coming year?

(Apologies for being behind on the routine end-of-year predictions, but I was AFI -- away from Internet -- and too depressed with predictions to make the journey. Still, duty calls!)

1. More depression for those who believe that security is important per se, and more profits for those who correctly balance risks with costs. We've pretty much buried the idea that security is a science and a business; the question is, can we integrate business and security?

2. This is allied with ongoing confusion as to what is illegal and what is not on the net.
   • KPMG shows that you can be too big to be criminal.
   • Online Gambling: you can do it but you can't pay for it. 'It' in this case is sports betting, but not poker, and only if you are listed on the London bourse, but not if three quarters of a year have passed...
   • Encrypted disks are great if are in the employ of the USG (see in boring link on crypto bakeoff), but not so great if you're hit with RIP. What does the US Ambassador to Great Britain do with his private emails?
   • Or online payments are another; if we don't like you we'll accuse you of supporting child pornography and let you argue it before the judge. Closer to Financial Cryptography -- e-gold is the issuer that refuses to die. The real dirty secret is that the Feds are so deep into e-gold at this stage they won't kill it, even as they are trying to kill it. This is -- I can reveal from first hand -- something that the founder predicted. Unfortunately under this scenario, the integrity of gold, the privacy of the user base, and the founder are all optional; something that I predicted. Sometimes it is annoying to be right, but it downright sucks if you are still part of the scenario.

   In echoes of the Sony versus Cuthbert mess of 2005, it all adds up to: "it's OK if you can get away with it," a message much reinforced by politics. There are no rules you can rely on, and everyone struggles to keep up with the results.

   For this reason, I dub 2007 the year of the platypus! What more confabulated animal is there than our world?




3. I think it is time to predict a boost in human integrity products. It can't have escaped the world's notice that much of our current strife is based on deception being so deeply institutionalised that it's now come around to bite us. There's a market waiting to be developed: how to cut down the deception in the process.

   The crying direct need is for such a product or process in employment processes. That's old news given Michael Spence's seminal work on signals about 30 years back, but what is curious is why nobody has really stepped in to look at it? A serious idea for b-school types or economists? How do we get away from Spencarian Signalling and put integrity back into employment interviews?

   1

4. Phones will continue to evolve and also become much more open. Currently, what holds them back is the closed architecture and infrastructure, but more signs are that emerging that this will be challenged. Good news, as it keeps the major players honest and fresh to have at least some "leakage."

   Some evidence: an open phone, this phone called me on Skype, a Cordless phoneset delivered with Skype, and today's news: Apple's iPhone does wifi and runs OSX.

   Expect cellphone cross-over to wifi as routine by the end of 2007. The ability to redirect calls to the net dramatically changes the competitive position of the telcos, and the open platforms make software development a low cost reality.

5. Payments and Chat. The one to watch is Skype, forget the rest as they don't have the security base. If Skype succeeds, they will change the scene, and even if they fail, but others might get the idea as to why it is good to secure the infrastructure.

   Why do I say that? "Been there, done that!" Chat goes with payments like Molotov with cocktails, Eddy with Patsy, Blue with Danube, but to see that you have to see the full design. The blue touchpaper has been lit, stand well back.

6. Any Company An Issuer. Well, actually this happened in 2006 and before, but it is now time to realise the core lesson here: all companies can now be issuers of money. They do this by the expediency of pre-paid gift cards.

   This is very significant, historically. Very Very Signficant: it is the end of the central bank monopoly on the control of issuance of money. As CBs are no longer the only issuers of money, we can historically mark the 20th century as the century of central banking, and the future is now refreshingly open.

   Of course, we will see much hand-wringing and bemoaning of the lack of control. Also a stream of pointless and annoying regulations, audits requirements, quasii-bank statii and what-have-you. But the genie is out of the bottle.

7. Which leads to a resurgance of local community currency issues. This can now be clearly demonstrated as something that is quite reasonable to do. That is, if a company can sell you a gift card, then a community can, too.

   And, it is also important to remember one of last year's very significant events, something so awesome that I never wrote it up on the blog: the Nobel Prize for Peace was awarded to Mohammad Yunus and the Grameen Bank. The significance of that event to financial cryptography is simple: their work is FC work, they just did it without our help.

   The reason I know this is because around 2001-2003 I was involved in a company that tried to do it. The application epitomised by Grameen Bank, financial lending from large western sources to small 3rd world borrowers, is pure FC at its finest. (As RAH would say, of course, you can only do it with a system that shows 2 orders of magnitude savings in costs.)

8. In 2007, we finally accept that we lost the battle to keep the world secure by ethical anonymity; the safety of the masses can no longer rely on their relative obscurity. What convinces me is not the biometric passport, the headline breaches of public trust in the name of war on today's bogeyman, but the gullibility of the average parent Sure there's always a good reason, but aren't all suppressions of liberty for good reasons?

9. The DRM wars have been won and lost. We will see a string of stories about how hollywood is selling alongside pirates and how piracy suppliers don't recommend piracy. The majors have got the message; they can't beat this thing, and they may as well evolve.

   This doesn't mean the end of RIAA raids and other dirty tricks. The war goes on, and battles will still be fought to keep the lid on territorial submissions. It also doesn't mean the end of cash cow economics. But it does mean lots of experiments ... on both sides ... as IP owners loosen their control on their property and p2p entrepreneurs get to grips with business models.

10. AES will suffer a big embarrassment. Switch to AES256 as Pareto-secure, and re-invigorate the research for Pareto-complete algorithms. The reason for this? When an encryption algorithm breaks, the mere sniff of weakness destroys all trust. Expect that odor to waft around in 2007.

11. Hashes will limp along under a cloud but nobody much will care, except the cryptobureaucrats. Mostly, this is because of implementation issues, where protocols implementors ignored the signs and did not switch forward to longer hashes. The reason for this? It ultimately doesn't matter, even when a hash algorithm is suspect, it still works well enough. Hashes don't smell, they are Pareto-secure for most applications.

12. Vista will "fail". Not in obvious, journalistic terms, but in long term trend market share. The reason? Not because they didn't try, they tried really hard, with feeling this time. I award them full points for effort. But...

    a. It's because Microsoft didn't understand the core weakness of security: marketing comes first. There is now sufficient evidence that they've allowed marketing to take over and drive fundamental architectural decisions which clash with security requirements we were promised. Specifically, they prayed to the false god of DRM, and the god took them for a ride. It is also the god of perpetual mirth, notching out Bachanus for hilarity. Contrast with Apple's approach, if you still aren't seeing it.

    b. It's because the industrial criminal sector migrated through the easy ones and are now adept at the sophisticated ones. They can now take on new opportunities faster than responses. MITB is "game over" unless Vista is more secure than the market place will accept. Microsoft is stuck between a rock and a hard place; BCG says "cash cow."

    c. It's because the economics of the OS has shifted. The third world cannot afford those prices, so they will go Vista if they can steal it, or Linux of they can't (which means they can switch easily to Mac when they can afford it). Given that most all growth is in non-1st world markets, that's kind of important to the overall game plan. Again, another rock and hard place for Microsoft.

13. Hence, the operating system market will continue to migrate to a more "regular" market.

    z.b. Mac OSX and Macs will continue to acquire "all" real growth in marketshare in the 1st world, where people can afford it. Microsoft may see a buzz of pent-up activity burst through on the release in Vista, but with discouraging real take up, where it counts.

    z.c. Linux up. *BSD stable or down, but up if we include OSX. Better if they can keep up their reputation as being the serious man's free Unix, the professional's alternative to Linux. Worse if they don't keep up with the application install blues; perhaps they should look at stealing Apple's pkg system.

    z.d This will add costs to software developers as they are forced to support more platforms, but will also improve the overall security through diversity and also the recovery of competition. This might become the way consumers pay for security, who knows?

14. On that old hobby horse: Phishing:
    • The certificate market is moribund and distracted. Notwithstanding the basic economic flaws, the major and minor cert providers will dance around the Extended Validation certs until they all realise the game, and they all realise that all realise the game, and they all realise that they all realise that ...

    • And still no concentration on the underlying systemic issues of the faulty operating system and the faulty browser... That really can't happen until certain unnamed manufacturers get their teeth kicked in by courts, press, or phishers. I do not predict this, because I have a perfect record of getting that one wrong.

    • Real retail payments security is now to be done by analysing the transactions at the backend. "In the interim, we'll look more closely." Until the secure terminal market shakes out (cellphones? PDAS? they're trying them all) there isn't much choice; and to be fair, this is how credit cards built their success, so why change something that works?

    
    

That's it, folks! Have a happy if confused year, evolutionarily speaking.

The year of the Bull: The predictable rampage in review ...

Last year I made a bunch of predictions. They were mostly accurate, so I'll not mail out this one; I'll just update if something comes along.

(Warning. Read this only alongside last year's predictions.)

1. Government intervention ... and in spades! You really truly don't want to read evidence of that, it's way too depressing for the holiday season, characteristically of good cheer and humour.

2. Anti-virus manufacturing reputations: darkened by "the MITB conspiracy" and shattered by "the Sony Affair." They are part of the problem as well as part of the solution.

3. Firefox crossed GP 1, 2, 3.

3.c I never saw any mention of that from Mozilla :-) I wonder how else they will develop their governance and discipline?

OTOH, Mozo employed a Chief Security something or other, Window S. A very welcome step, but the hard work within is unlikely to be really recognised.

4. Gift card rollouts abound. It would be worth a post about the rise of corporate money (I first "discovered" this in 2003 or so), but central bankers won't read it, and others won't need it. Evidence: 1 ... Hyperion Consulting are in the business, so take their comments seriously (unless you are a central banker).

5. Gold issuers are cowboys. Where's that wired link again?

6. Mac share up 30% in US ... 1 while PC sales increased 0%. I guess that means from 5% to 6.5%, which is a shade under 7-8% predicted.

6.b Yes, I'm typing on it! Yes, the UI is hateful. Its "intuitive" reputation is just doublespeak. I've also found the application poverty to be depressing, which surprised me. KDE and FreeBSD are much better equiped, IMO, once you get over the hurdle of installing the monolith in your bathroom. E.g. there have been no piccies posted on FC in ages ... coz I can't figure out how to shrink an image on Mac OSX.

OTOH, Mac OSX does seem easier to keep up to date than the others.

7. google up. But no adverts in cat herders. Instead, it seems that their policies are still working, as long as their hiring maintains its quality. Like the USD, we know it will fail, we just don't know when. (There was a long blog post on their hiring strategy but I don't have it to hand.)

8. MS security problems? Still unsorted. Vista now falls into the legend to become next year's predictions...

9. Mac OSX wasn't troubled, security wise: 1.

10. The perfect phish and realtime phishes -- so I got two out of three. No class action suits on phishing, as yet, and I didn't predict MITB. "Sorry 'bout dat" as they say in Mexico.

11. No mention of SSL as part of any security solution during the year 2006. That I saw. But who would dare show me? (Disclosure: I am now perversely conflicted. I audit an SSL security provider ... life is full of challenges!)

12. 2 factor on phones finally happened, YES! Banks in Europe have been rushing these out, faster than they can say "Europa". Why? Because of MITB. OOPS! Did I say I didn't predict MITB?

13. DRM? Yup, nothing much happened except more of the same.

Wanna dispute the point? Dispute this: 2.
The end-beneficiary of file-sharing continues to enjoy its leading arbitrage status. Obscurely, there is more in the soap opera of DRM, the hypist's favourite security drama, to follow, after the break.

How many people are turned away by the FC certificate?

Peter Gutmann asks:

Do you have any figures on how many security people your self-signed certificate is turning away? I'd be interested in knowing whether the indistinguishable-from-placebo effect of SSL certs also extends to a site used mainly by security people.

I have no idea! Anybody?

4th April, 1984

Winston wrote in his diary, some 22 years ago:

as he stumbled into the immoral task of pouring his overburdened thoughts onto paper. I say approximately, because there are a number of uncertainties in the source, not least the date. A bit later on, Winston meets an editor of the new dictionary in the canteen, who has this to say:

"It's a beautiful thing, the destruction of words. Of course the great wastage is in the verbs and adjectives, but there are hundreds of nouns that can be got rid of as well. It isn't only the synonyms; there are also the antonyms. After all, what justification is there for a word which is simply the opposite of some other word? A word contains its opposite in itself. Take 'good,' for instance. If you have a word like 'good,' then what need is there for a word like 'bad'? 'Ungood' will do just as well -- better, because it's an exact opposite, which the other is not. Or again, if you want a stronger version of 'good,' what sense is there in having a whole string of vague useless words like 'excellent' and 'splendid' and all the rest of them? 'Plusgood' covers the meaning, or 'doubleplusgood' if you want something stronger still. Of course we use those forms already, but in the final version of Newspeak there'll be nothing else. In the end the whole notion of goodness and badness will be covered by only six words -- in reality, only one word. Don't you see the beauty of that, Winston? It was B.B.'s idea originally, of course," he added as an afterthought.

George Orwell's 1984 remains the definitive word on how a population is suppressed for the benefit of a ruling class, for one agenda or other. The techniques that he describes are so powerful that they literally cut across ideologies, and it seems, across time and experience.

The message of 1984 rose in public consciousness as the year itself approached - recall the film, the songs? But then it started to fade, almost immediately afterwards. Choosing a year in the future as the title might have seemed like a brilliant literary device 40 years earlier, but are we paying the cost now?

Prof. Iang

Adam reports that the other Iang made professor. Top banana!

(Naming and name clashes are an ever-present issue in our field. It adds clarity to the conversation when we even have clashes at the meta level... Or so I claim.)

new cert for FC

Installing new SSL server certs is like visiting the in-laws for Christmas dinner. It's so painful, you dread it for weeks in advance. Afterwards, the relief flows through you as you know you don't have to do that for another year or two.

The eagle-eyed will notice a new certificate for Financial Cryptography, as of a week back. There have been a number of improvements: it now includes all the AltSubjectNames according to the VHostsTaskForce recommendation. It's also installed with the new Class 3 root, which is the CAcert "high-verification" root (meaning that the identity of the issuer -- me -- was checked at least to 50 points worth).

(You will need to reset your Trustbar. You should need to reset your Petname. Weird - for me, Petname is stuck on the old name transferred to the new cert???)

Getting the right setup only took 3 goes. One effort failed completely. Second time, the script I used did not include the CommonName as well in the AltServerName list. Apache barfed on that version, giving an uninterpretable error. Re-rolled with the right list, this time it worked.

There are still issues. Hopefully by the time this one expires, 2 years from now, these other problems will be solved as well:

• Apache and browsers will hopefully implement ServerNameIndication (SNI) which is the standard for sharing one SSL server over many web sites as Virtual Hosts. Like much of the planet, I have one IP# for too many web sites to administrate. Sharing virtual hosts is needed not to please me, but because it feeds into the fight against phishing. I already got hit with a request to add another domain name - which means a whole other cert, dammit.
• We'll be a bit closer to point, click, configure. CAcert's process for setting this all up is still slow and cumbersome, but at least the doco is mostly there within 10 minutes or so of it being needed. The entire process took most of my last saturday, and I won't be satisfied until the time takes less than a minute, like Skype or SSH. Crypto is meant to help protect us, not slow us down and burn up our weekends.
• Although CAs make a statement to some effect, users still don't know it. Firefox tells me the site name on the bottom, but not who said that unless I mouse-over. Safari doesn't even do that, it is still on the old model of a tiny padlock hidden somewhere. Konqueror proudly announces how many bits of crypto blah blah protection I've got. So basically users trust their browser or they are SOL.

Readers sometimes ask why FC uses CAcert instead of forking out bux to the commercial companies. It's not a political statement, I'd frankly rather we could just use crypto without the hassle (names of well designed cryptosystems available on request). Here's some of my reasons for using CAcert:

1. I have a bunch of sites. They all benefit from a bit of SSL, but even at the low prices of certificate manufacturing shops, that all adds up. Also, one needs to factor in errors, reworks, extra domains added in, etc. With CAcert, it is only my time going down the drain every time something doesn't work out, not my wallet.
2. CAcert have an identity program that makes sense, at least in principle (an audit process has started recently). They use what they call a web of trust and have each issuer of class 3 (identified) certs checked out by two or more people, face to face. It's not that I care to be checked out like that - in fact I despise and loathe the idea that to use crypto you have to know me - but if we are going to make a statement about identity, let's at least make a statement that means something. As a Financial Cryptographer, it behoves to take part in a process that is coherent, to the extent possible; in the past, I've used credit cards, but because I know that is a meaningless identity check, I feel stupid doing it. (FTR, I myself have 55 points which means the certificate points to an identity that was verified by at least 2 independent assurers, each of whom have at least 100 points, and are therefore verified by 4 people each, as a minimum.)
3. CAcert is building a membership structure that harkens back to the good old days of the net. Members work for each other. The doco is patchy and the accents are odd, but the lists are not antagonistic to the honest user who lacks a PhD in mathematics. Security for the common man. And you get free certs. As there's no interest in how many certs are sold, concentration on core security is more likely. In fact, over on the CAcert lists, it's possible to propose some interesting security ideas and get some thoughtful response. Very refreshing.
4. Readers will recall the age-old scandal of phishing. One core weapon in the fight against phishing is to get as much traffic onto SSL as possible, and then tools like Trustbar, Petname and maybe Ping's new design can better protect users. It's a virtuous cycle - more SSL means more certs means more tools and more protection. For ordinary users. So it pays for us financial cryptographers to keep the pressure on for more SSL. CAcert is definately there to help that process. Who else is? Whatever your views on whether High Authentication will work, it is hardly designed to increase the amount off SSL in use.

Of course, not all is light, joy and bounty. Far from it, CAcert is only the least worst of a bad bunch, but if we want to address phishing something must be done. A couple of notable flaws in the CAcert process: Their docs are all scattered around and their processes have not been beaten up. The linkage from the relying party to the cert to the signer to the statement to the CPS is unclear (but that's common of all).

( Note to FC readers: CAcert's root is currently only being distributed into various Linux distros and now FreeBSD! For other platforms, you will need to travel to CAcert's root page to install the root into their browser by hand -- for Firefox users, click on the line that says Class 3 PKI Key Root Certificate (PEM Format) if want to be part of the CAcert community. For Safari, Konqueror, Opera, IE7 users ... I don't know. I tried to load the root into Safari but failed. )

Brickbats and Plaudits

Occasionally people actually write in to say how they love or hate the blog or the various other rants! Rather than lose these, I'll publish them here in most recent order:

From Chat, Hasan says:

Here's an unexpected comment from Frank Trotter:

The post on Diamond Governance sparked some contoversy! I'll dogmatically work up an unprejudiced reply :)

Christmas Day - the first day of this entry - is probably a good day to post good news:

This is a dynamic entry.

IFCA's Discussion Maillist for Financial Cryptography

Hello and welcome to all on the IFCA discussion list.

As Ray posted this last weekend, he has invited me to take a more active role in the list. Although termed 'moderator' I would like to think of it is more of an encouraging role than moderating role.

To that end, I've added the IFCA discussion list to the notifications list on the Financial Cryptography blog that I keep at http://financialcryptography.com/ . This means that any blog posts will be forwarded to the list, one of which you will just have seen. On long term average, that's about one per day.

For those who follow the blog - this means we now have a more conventional forum on which to discuss the posts. We've all recognised that the blog's comment mechanism is less dynamic than a mail list, as we don't get to see other people's posts. Hopefully the IFCA discussion list will rectify that lack.

If you wish to subscribe or unsubscribe from the IFCA discussion list, here are the vital statistics as copied from every post:

> fc-discuss mailing list
> fc-discuss@ifca.ai
> http://mail.ifca.ai/mailman/listinfo/fc-discuss

Ray has installed the familiar MailMan interface which allows easy follow-your-nose administration. If you are subscribed to both you will see two copies each post, so let me know if you want to unsubscribe from the blog list (which is manually administered only).

New Machine for FC

FC is now mounted on a new machine. It's faster and so is the network. This might even work, if you can see this, it probably is! Let us know of any problems.

A Pennyworth of thoughts

In emerging countries, the plan is simple: first, let the people sort out the money. Second, teach them about governance. China is now in the second phase as the grapple with a series of expensive lessons as the new breed of capitalistic bank managers calculates the difference between their salaries and poor governance.

And over in the Germany, the unlikeliest of things: a task market approach to jobs. Seems like some wicked Austrian (economics) person has set up a market for employers to post jobs, and the auction principle takes the price down down down until the lowest bidder wins the job.

Goldmoney continues to grow, but lack of any data on customers remains a huge problem for the sector. Here's a clue - not all is well with users as they suffer inordinate delays in getting access to their money, where inordinate means 2 months! The reason for the delay relates to goldmoney's desire to be a responsible member of the financial community, or at least to get the regulators of their backs. Sadly, it means their customers don't get to feel as though it is their money.

Statistically, there have to be some people who've worked out that the problem with today's identity theft is the 'identity' part. Here's an article by Hiawatha Bray who has figured it out.

In more perceived shift to open security, banks are being exorted to get it off their chests, and reveal their security problems. One part of us knows that could be a long story, another part of us is shocked that they have any problems at all. Nothing gets fixed on security until we bring the divergent viewpoints back to reality.

Open Peer Review

Following on from discussions on peer reviewed papers, I checked an up and coming conference (Econ & Security), and the call for papers had closed. Adam points out we should invent an open peer review process, so as my curiosity is piqued, here is a proposal of sorts.

Take a paper and blog it in some fashion. (Perhaps limit the blog entry to the abstract and a link to the full paper.) Then, open the blog entry for comments and trackbacks.

Hey presto, we have peer review but not peer gatekeeping. (So far this was all Adam's idea.) We can also include substantial milestones such as major review periods, closing off one blog entry and shifting to another when the author has enough material to rewrite.

Reputation is built in as over time, the volume of attention should indicate the importance of the work. Let's draw a line in the sand and say that papers should be licensed under a Creative Commons licence.

Now, blogs already do this. But they are spontaneous, free flowing and full of spelling errors. So in order to turn the blog more to a weighty forum suited to the gravity of academia, we could put some links on the blog front page indicating the papers under spotlight.

Has anyone got an FC paper ready to roll? As Digital Money and FC-conference have just passed, and Econ&Security is closed, there seems to be a bit of a hole for the next 6 months in the peer review process. I would point out that the workshop in Electronic Contracting is open for another month. Oops, no, it's closed too. Double-oops. It's cancelled for lack of critical mass! Well, that just goes to show how hard the conference game is - having been there myself.

Having said that, in general, most of these conferences presume that Internet discussion does not count as publication. So you can have the best of both worlds, you can take advantage of a blog peer-review forum to hone your argument, then go for old world dead tree publication as well. (As long as you are careful not to muck up the licensing...)

A Fistful of Pennies...

Having read the 1st chapter of Simson Garfinkel's dissertation I'm bursting to ask a simple question: what's the working title? But Simson's blog won't take the comments he asks for. Maybe a trackback will work?

Bob says the Tampa Tribune reports "More than one-third of Internal Revenue Service employees and managers who were contacted by Treasury Department inspectors posing as computer technicians provided their computer login and changed their password, a government report said Wednesday." Well of course, how else do people fix up the minor errors in their tax filings?

In London police have foiled a cyber cracker who used key logging software to infiltrate Sumitomo bank. Nice to see that old fashioned security work did the job, and there is no cover-up. However, I'm unsure what people mean by "massive" when a hacker can choose for himself how many zeros to type in...

I've changed the name of the category "Security" on the blog to "Risks & Security." I'm not quite brave enough to ditch the word security, as exhorted to by Cubicle. We'll see how this floats.

News just in from the second Workshop on Electronic Contracts (WEC) is that it has been cancelled through "not reaching critical mass." It got a good start at the first one, where my Ricardian Contract was presented by Mark Miller. The conference game is quite hard - things can click together, and they can just as easily fall apart.

And in closing, there is a special on Internet Organised Crime. I haven't read it but there are a dozen articles there.

Lessig says 'never again' to copyright demons

In a slightly related development reported by Adam, doyen of the anti-copyright revolution, Lawrence Lessig has said he won't distribute his work any more unless under a decent sharing licence. Hear hear! I would like to do the same; and would encourage the various publishers to get with the programme.

Lessig chooses the Creative Commons Attribution-Noncommercial licence as his line in the sand. I'll think about that. I have a paper that is now ready to consider the wider peer review - the Pareto-secure one. Maybe it's time to test these theories with real words and works.

FC itself is currently under the straight Attribution licence, which likewise is attributed to the Creative Commons effort.

More Pennies

Stefan posted a bunch of materials on a phone based ecash system.

On Identity theft, America's cartoonists are striking back. Click here and then send me your credit card number....

On the HCI thread of how users view web security, Chris points out that "Simson Garfinkel's dissertation is worth looking at in this context." This relates to the earlier two papers on what users think on web security.

Scott reports ``Visa International has published a white paper titled "Financial Flows and Supply Chain Efficiency" (sorry, in PDF) authored by Professor Warren H. Hausman of Stanford University.'' It's interesting if somewhat self-serving, and feeds into the whole message is the payment thread.

Stefan via Adam pointed me to a new blog on risks called Not Bad For a Cubicle. I shall pretend to know what that means, especially as the blogger in question claims knowledge of FC ... but meanwhile, the author takes task with persistent but poor usage of the word security, where 'risks' should be preferred. This makes a lot of sense. Maybe I should change all uses of the word over?

Because it's more secure becomes ... because it's less risky! Nice. But, wait! That would mean I'd have to change the name of my new paper over to Pareto-risk-free ... Hmm, let's think about this some more.

Pennies

Small things I have come across recently:

Vonage chooses VeriSign's managed subpoena service!. See NetDiscovery one and two for background.

Adam points to a new security blog called Be Careful Out There. He suggests that browsers need to change and takes aim at security gurus. His claim that the RSA conference is a Solipsistic Oligopoly resonates with Adam's pointer to this post on Own OODA Observation Loops comment.

In the financial applications world, JPM points at Zopa which claims to be the first lending and borrowing exchange. How, one asks, is this going to work without a qualification of the borrower? And if that is unanswered, how much can I borrow!

Another payment niche player in the remittances business. This is something that's sitting there waiting to go, the majors are too fat and stuck in their ways and will get shaken down.

Threats department: IM threats growing 50% per month, Luckily these are unstandardised and disparate systems, so they can migrate and evolve. Oh, and Choicepoint made the Economist with What's in a name?. Congrats, I think.

Finally, Senge on learning says that too little listening is done, and info without learning is wasted. After reading, there will be a test...

PayPal plus eBay - it's FC, not banking

FCers will recognise the confusion in this article by Kevin Kelleher about how to analyse eBay + Paypal:

"Here's a little-known fact about eBay (EBAY:Nasdaq) : It's not one of the most successful e-commerce companies in the world.

It's actually two of the most successful e-commerce companies in the world -- eBay, the global network of auction and retail sites, and PayPal, its online-payment technology subsidiary that fuels the bulk of eBay transactions. Of the two, PayPal may emerge as the bigger phenomenon in the long run."

FCers see further than trying to model a payment system as a bank; it is a financial cryptography system that happens to have branded its Value structure. The Finance component is the auction, and the fact that the two companies grew up apart and together is simple reflection of the FC observation that you need both the finance and the value.

FC discussion list

For those who prefer a more traditional mailing list forum, Ray reminds me of a discussion list for matters FC! Subscribe here:

http://mail.ifca.ai/mailman/listinfo/fc-discuss

I shall forward this post out to there. One question: should I forward all the FC blog posts to there?

What is FC (iv) - The Payment is the Message

So pick an application, any application. "Here's one I just happened to have prepared earlier." Let's Start at the Top.

Imagine a decent payment system. I mean a really decent one, with reliable payments and proper client server architecture. So rule out Paypal, the IGs, and any online bank. But, include SWIFT, settlement systems, and the like. Well, maybe, you be the judge on that one.

What's going on with these systems is that they are message based. And, indeed, they can be used as messaging systems. When you send your wire through the monetary black hole also known as New York New York, your two losing banks sends messages over the same system to try and find the money. (This happens in excess of 50% for my international dollar wires.) Eventually the messages meet in the middle and some clerk remembers to crank the handle or feed the mouse to get the wheels of banking rolling again.

It's terribly unreliable, but it *is* messaging and the messaging is analogous to proper reliable messaging systems. It's used in exactly the same way as you or I use an instant messaging client or a mail client. Except it also does payments...

So what would it be like to add instant messaging to an Internet payments system? Or, to add payments to an Internet chat system? Well, for one, it would mean that we'd never lose another payment through human error, because the system that is used to do the human layer - that protocol known as conversation - is the same as that of the payments layer. While I'm chatting with my counterparty, I fill the box with the number and hit PAY. My computer does the rest, including guaranteeing that the right person gets it, instantly.

For another, once we have a messaging system, we can send invoices. As I'm working, I click on "Invoice", select "template #3", add an amount, and hit send. While I'm chatting, the invoice pops up on my counterparty's chat window. Her window happens to know what it is, and asks her "Pay now? Or Pay later? Or reject?" Couldn't be easier ...

In fact, once payments and IMs are intermingled, whole vistas are opened up. Pausing for breath here, it may well be that the reason EDI, ITP, and a squillion other ventures with too many acronyms didn't work was because they lacked two things: a payment system and a messaging system.

So that's my application. And here's my requirement: The Payment Is The Message. Or, The Message Is The Payment!

How to build this? That's the challenge of FC. Clearly, not from scratch. One either takes a payment system and adds chat, or, one takes a chat system and adds payments. I chose the former, because a) I had a payment system, and b) the reliability of payments dominates the reliability of chat. So it was a case of detuning in a lot of respects, which is easier than .. rebuilding.

Now, the requirement above says we have to make a payment system act like a messaging system. This immediately creates for us a few derivative requirements. Firstly, a client has to talk to a client in live form, which means a server has to talk to a client, in live, unsolicited form. Secondly, a client has to accept those unsolicited live messages coming in. Thirdly, the messages want to be of open, user-supplied format, somewhat.

To date, most payment systems have been "pull" in that the client goes to the server and pulls the data down. Our derivative requirements above break the pull model. To deal with "push" requires the server to be able to send a stream of unsolicited messages to the client, which means a further requirement on the secure protocol: datagrams. As we aren't going to compromise security, this means crypto datagrams, flying in both directions, which means a new crypto protocol, because there isn't a convenient secure crypto datagram protocol. (There is now: SDP1 is used in SOX :-)

Further, payment clients are generally far too "pull" oriented. This means proper multithreading and integration with GUIs. (Ours didn't cut it, and had to be rewritten. That took an age. This also means that certain client technologies are going to suck at the future landscape of payments, and we are entering a new age of client confusion as capabilities fail to converge with desires. But that's another rant.)

So, having isolated our requirements, and driven them down into layers of requirements, all that is left is implementation. Skip forward to the present, and I can now demo chat over payments. Or was it payments over chat? Either way, we are now well placed for phase 2: experimenting with invoicing, p2p trading, and p3p activities.

Adding instant messaging to the Ricardo payment system was no easy task. It involved the two quite mammoth changes mentioned above. But, the result is simply awesome. I don't think it's an exaggeration to say that this is a major result for Financial Cryptography - setting the requirement as the payment is the message is the payment is like the missing link in ecommerce evolution.

Suddenly, everything that people were dreaming of in the mid 90s becomes easy. Suddenly, not being able to reliably intermingle payments with messages looks very honky indeed.

And this is where FC gets its magic. It's a top-down application concept. Start with the application - the finance layer - and set your application goals. In this case, it was to add messaging to a payment system. Then, drive those goals as requirements down until you have a working concept.

Just as a total coincidence, we ended up with new crypto in there. Writing SDP1 was fun! But it was also totally application driven - and in fact it wasn't until we got to the point of actually needing it that we knew that crypto datagrams needed to be done. It was so small and trivial in the application scope of things, it got left out of the high level architecture as too trivial to mention.

That's what FC is: take an application of financial importance. Set goals, break them down, go deep down. Goals, Requirements, Layers, ... Probably, your journey ends with crypto. Sometimes it doesn't, but that doesn't matter. What matters is that what is *required* in an FC application is found and implemented.

And maybe we snuck some crypto in there for fun.

FC exile finds home as Caribbean Brit

Vince Cate (writes Ray Hirschfeld) created a stir a number of years ago by relocating to the Caribbean island nation of Anguilla, purchasing a Mozambique passport-of-convenience, and renouncing his US citizenship in the name of cryptographic and tax freedom.

Last Thursday I attended a ceremony (the first of its kind in Anguilla) at which he received his certificate of British citizenship.

But Vince's solemn affirmation of allegiance to Queen Elizabeth, her heirs and successors was done for practical rather than ideological reasons. Since giving up his citizenship, the US has refused to grant him a visa to visit his family there, or even to accompany his wife to St. Thomas for her recent kidney surgery. Now as a British citizen he expects to qualify for the US visa waiver program.

Is this the end of an era, a defining cypherpunk moment?

What is FC (iii) - Start from the Top.

In terms of definitions for FC, applying crypto to banking and finance doesn't work. Mostly because those doors are simply closed to us, but also because that's simply not how it is done. And this brings us to the big difference between Bob's view and FC7.

In Bob's view, we use crypto on anything that's important. Valuable - which is much more open than, say, the 'bank' view. But this is still bottom-up thinking and it is in the implicit assumption of crypto that the trouble lies.

Applications are driven top down. That means, we start from the application, develop its requirements and then construct the application by looking downwards to successively more detailed and more technical layers. Of course, we bounce up and down and around all the time, but the core process is tied to the application, and its proxy, the requirements. The requirements drive downwards, and the APIs drive upwards.

Which means that the application drives the crypto, not the other way around. Hence it follows that FC might include some crypto, or it might not - it all depends on the app! In contrast, if we assume crypto from the beginning, we're building inventions looking for a market, not solving real world problems.

This is at heart one of the major design failures in many systems. For example, PKI/SSL/HTTPS assumed crypto, and assumed the crypto had to be perfect. Now we've got phishing - thanks guys. DigiCash is the same: start from an admittedly wonderful formula, and build a money system around it. Conventional and accepted systems building practices have it that this methodology won't work, and it didn't for DigiCash. Another example is digital signatures. Are we seeing the pattern here? Assume we are using digital signatures. Further assume they have to be the same as pen&ink signatures.... Build a system out of that! Oops.

Any systems methodology keeps an open mind on the technologies used, and that's how it is with FC7. Unlike the other definitions, it doesn't apply crypto, it starts with the application - which we call the finance layer - and then drives down. Because we *include* crypto as the last layer, and because we like crypto and know it very well, chances are there'll be a good component of it. But don't stake your rep on that; if we can get away with just using a grab bag of big random numbers, why wouldn't we?

And this is where FC7 differs from Bob H's view. The process remains security-oriented in nature. The people doing it are all steeped in crypto, we all love to add in more crypto if we can possibly justify it. But the goal we drive for is the goal of an application and our solution is fundamentally measured on meeting that goal; Indeed, elegance is not found in sexy formulas, but in how little crypto is included to meet that goal, and how precisely it is placed.

The good news about FC7 is it is a darn sight more powerful than either the 'important' view, and a darn sight more interesting than the banking view. You can build anything this way - just start with an 'important' application (using Bob's term) and lay our your requirements. Then build down.

Try it - it's fun. There's nothing more satisfying than starting with a great financially motivated idea, and then building it down through the layers until you have a cohesive, end-to-end financial cryptography architecture. It's so much fun I really shouldn't share it!

What is FC? (ii) - Debunking the 'Bank' View

Yesterday I outlined 3 views on "what FC is," yet there were some obvious differences. If I can call a token money system using big random numbers as FC, and the academics say that FC is crypto applied to banking problems, then we have a conflict. Banks don't buy random numbers! Which then is the more useful view?

I shall answer this by elimination, and in the process, debunk the 'bank' view. Mostly because it is easier to do that than to prove the alternate!

Firstly, banks do not buy crypto. What they buy is security. They buy secure systems from reputable suppliers, all of them called IBM. (Remember SET?) So whatever it is that banks do, that could be FC but it isn't crypto.

Banks buy systems and processes. Sometimes those systems have some crypto in them, and sometimes not. IBM are experienced in creating a complete process, and if their architecture calls for crypto, then that's what will be in there. But, it's entirely optional, it all depends on the requirements.

This is because applications are driven top-down. Requirements are laid out and they are driven down through various layers, with each layer attempting to cover as much as possible. By the time we get down to the murky depths of crypto, most all decent architects would be somewhat depressed if their crypto needs were exotic. As well as potentially out of a job; any architects who started out thinking about crypto would be totally irresponsible. Systems are built to requirements, not cool formulas.

Further, even when we get to adding in some crypto, the quantity in any given system is generally quite low. Maybe about 1% of the lines of code in a software system. (If the key exchange stuff is done properly, a couple of pages in the manual.) So, what's all the fuss about?

Finally, there is a further problem with banks - they don't do anything that other banks aren't doing. This chicken&egg problem is called 'herding' and it's an economics term of art. From this, we can conclude that banks don't do exotic crypto.

Which leaves us where? If FC is crypto as applied to banking systems, we've got some real issues in making that 'interesting': It's small. It's bottom-up. It's not sellable and it's not wanted. It's also not professionally responsible.

(Which all to a large extent explains the rise and fall of companies like DigiCash. But that's off the topic.)

It is in fact far far better to say that FC has nothing to do with the banks. The key is to turn all that around and look at other opportunities. Payment systems run by non-banks are fruitful applications. (And by non-banks I mean not-anything-like-banks.) Non-payment systems run by anyone are also important - think about trading, contract formation, reputational systems, identity, and new methods of accounting.

Or, consider it this way. The reputational auctions that Paypal helped, otherwise known as eBay, were as interesting as the payments. A large part of that success was because there wasn't a bank involved, as seen by the consistent exits by the banks.

(Next: Start from the top.)

What is Financial Cryptography? - a rant in 4 parts

Recent discussions have brought up that old confusion, just exactly what is FC?

I put down my view of that in FC7. Whether that's a good view only time will tell, and whilst not universally accepted, criticisms seem to be limited to "why isn't this or that in the layers?"

The question of FC is at the core of what the FC conference, starting this week, should be about. It's about why people should go and what they should expect to find at the conference, so the definition is something to think about. Here's my attempt to map it out.

First spot goes to Bob H who invented the term. Now, I don't know that he ever defined it directly, but he did define it by elimination: financial cryptography is the only cryptography that's important. That's a reversable definition - if it matters, it's FC.

Bob's definition does several things for us. Firstly, it establishes a value metric - there has to be a value involved, in order to 'be important.' Thus, it eliminates the military, government and 'national security' applications, which are 'beyond valuation' and it also eliminates things like encrypting messages for fun or paranoia which might be termed 'beneath valuation'. This simplifies things a lot as we can work from an assumption that an application is doing something of value.

Secondly, it has to be crypto. (Why that's important becomes clearer later.)

The academic view is much less well thought out. There is a sort of shared assumption that "banks and banking" are the target for FC. So, according to this view, the crypto should protect coins (Chaumian money) or ATM networks or wire transfers or something. Indeed, over on Wikipedia, it says "Financial cryptography is the use of cryptography in banking and similar financial applications." And it lists ... exactly those applications.

The third view has to be FC7. This is the 7 layer model that stretches out crypto and finance, finding an additional 5 layers in between. Those layers are either obvious like software engineering (2) or subtle like governance (5). They are either basic and boring like accounting (4) or open to much interpretation like Rights (3).

7. Finance	Applications for financial users, markets
6. Value	Instruments that carry monetary or other value
5. Governance	Protection of the system from non-technical threats
4. Accounting	Containing value in defined and manageable places
3. Rights	Units of authentication, with ownership of units of value
2. Software Engineering	Moving instructions over the net
1. Cryptography	Stating mathematical truths for sharing between parties

What's not so obvious is the corollary of FC7 that if you don't address all 7 layers in your system, your survival rate is low. But, this doesn't mean heavyweight employment. Indeed, a lightweight crypto layer is entirely acceptable, and one can even get by without any crypto at all, in some stretch of theory! A simple example of this would be a payment system using big random numbers as coins. It's hardly crypto, but it is drawing from the cryptographic thought process within an overall architecture.

Which brings us back to the academic view that FC is crypto as used in or by banks, and the Bob view that FC is crypto that values. Are these complimentary or orthogonal? Exclusive or intersecting? That's for another post!

FC - top picks for papers

My counter to Peter Wayner's article kicked up a bit of a storm, regretfully carried on in the hallowed but private halls of IFCA's internal mail forums. (Yes, I did ask when they'll put up a forum for members and others to discuss matters FC.) One thing that was curious was the volume of response; finally it twigged to me, the conference starts on Monday!

Well, I'm not there, I'm sitting in the snow. You're not there either if you're reading this. Here's my list of top picks for those talks that might have made the trip worthwhile.

But before I get onto that, I have to report: shock! horror! every paper is online ! Thank you organisers, thank you papers committee, thank you all! We can now read these papers, and fame and fortune for the authors is assured:

Protecting Secret Data from Insider Attacks
David Dagon and Wenke Lee and Richard Lipton (Georgia Institute of Technology)

Trust and Swindling on the Internet
Bezalel Gavish (Southern Methodist University)

Risk Assurance for Hedge Funds using Zero Knowledge Proofs
Michael Szydlo

Probabilistic Escrow of Financial Transactions with Cumulative Threshold Disclosure
Stanislaw Jarecki (UC Irvine) and Vitaly Shmatikov (UT Austin)

A User-Friendly Approach to Human Authentication of Messages
Jeff King and Andre dos Santos (Georgia Institute of Technology)

Panel: Phishing - Organizer: Steve Myers
Tentative panelists: Drew Dean, Stuart Stubblebine, Richard Clayton, Steve Myers, Mike Szydlo

Cybercash on Vacation - ruminations on FC

Peter Wayner has written a downbeat piece on the history of the Financial Cryptography conference. He asks a bunch of people why FC hasn't taken off, and gets a lottery of answers. I think he's wrong...

The ideas have infiltrated into places, but few have noticed. PayPal did find some sustenance in the process, as did the gold currencies, and certain of the ideas that were talked about are now internalised. They simply didn't tell the FCers. Other more conventional plays such as ETFs have simply adopted the models from those players, and again, they've not recognised where they came from. Either publically or privately.

The reason for this lack of feedback on success - and hence the apparant lack of success - is because the FC organisers lack one thing: perspective. They were either academics, security guys, geeks, cryptographers or netizens. Often they were 2 or even 3 of those, but rarely did they have a straightforward business ability to integrate the ideas into other spheres. It was this integration that I wrote about in the 7 layers paper, and it is this integration that people like Dave Birch speak of in the conferences he runs.

When business people attend the 'vacational conference' of FC, what they see are a lot of different ideas expressed as fomulas, and it is left to them to construct them into business context. The fact that they didn't then credit FC with their successes is a foregone conclusion, as the FC community isn't capable of understanding the perspective that they are offering. That doesn't mean it wasn't there, it is just that until organisers stop treating FC as a forum to present new equations, they won't have the language to recognise what it's about.