Financial Cryptography

Happy New Year

May 2005 be better than 2004, 2003, 2002, 2001 and so on. The previous years have been graded to determine the mean and referenced to 1999 as a benchmark for happiness. All claims and wishes are based on objective results and cannot be understood to be a promise by the party wishing a Happy anything. This wishing contract has been reviewed by the attorney of the wisher and those wishing to serve legal action based on acceptance of this wish will kindly be directed to the sender's office for service. If an error should occur in transmission such as swishing versus wishing then the reciever has the option to carry on at will without holding the sender liable. The wishing versus the swishing debate is now in Congressional review and updates will be provided. In addition to the Wishing/Swishing issue the Phishing issue has been determined to be a 2004 problem that will not be carried into the 2005 year. So all those wishing/swishing/ phishing in 2005 should stop immediately and simply wish a Happy New Year. (Written by Jimbo!)

Netcraft breaks ranks and points the crooked black claw of doom at the SSL security model

In a show of remarkable adeptness, Netcraft have released an anti-phishing plugin for IE. Firefox is coming, so they say. This was exciting enough to make it on Slashdot, as David at Mozilla pointed out to me.

There are now dozens of plugins floating around designed to address phishing. (If that doesn't say this is a browser issue, I don't know what will. Yes, the phish are growing wings and trialling cell phones, pagers and any other thing they can get at, but the main casting action is still a browser game.) The trustbar one is my favourite, although it doesn't work on my Firefox.

So, what about Netcraft? Well, it's quite inspired. Netcraft have this big database of all the webservers in existance, and quite a few that are not. The plugin simply pops on over to the Netcraft database and asks for the vital stats on that website.

Well, hey ho! Why didn't we think of that?

There's a very good reason why not. Several in fact. Firstly, this puts Netcraft into your browser in an important position; if they succeed at this, then they have entre into the user's hearts and minds. That means some sort of advertising revenue model, etc etc, as clearly permitted in their licence. Or worse, like their own little spyware programs which may or may not be permitted under their Privacy clause.

(So one reason we didn't think of that is because we all hate advertising models ... just so we're clear on that point!)

But more interesting is that Netcraft is a player in the security industry. At least, they are a collector of CA and SSL statistics, and their reports sell for mighty big bucks. So one might expect them to pay attention to those suggestions that supported the SSL industry, like the ones that I frequently ... propose.

But, no. What they have done is completely bypassed the SSL security model and crafted a new one based on a database of known information. If one has followed the CA security debate, it bears a stunning similarity to the notions of what we'd do if we were attempting to fix the model. It's the endgame: to fix the revocation problem you add online checking which means you don't need the CAs any more.

Boom. If Netcraft succeeds in this approach (and there is no reason why others can't copy it!) then we don't need CAs any more. Well, that's not quite true, what this implies is that Netcraft just became a CA. But, they are a CA according to their rules, not those historical artifacts popularised by accounting entities such as WebTrust.

So it's another way to become a CA: give away the service for free, acquire the user base, and figure out how to charge for it later. A classic dotcom boom strategy, right? Bypass the browser policy completely because it is struggling under the weight of the WebTrust legacy, and the security wood can't be seen for the policy trees.

(Now, some will be scratching their heads about the apparent lack of a cert in the plugin. Don't worry, that's an implementation detail. They can add that later, for now they offer a free certificate service with no cert. Think of the upgrade potential here. The important thing is to see if this works as a *business* model first.)

So this takes aim at the very group that they sell reports to. Of course, the people who want to buy reports on certificate use are the CAs, and their various suppliers of CA toolkits.

That's why it's a significant event. (And another reason why we didn't think of it!)

Netcraft have obviously worked out several things: the CAs are powerless to do anything about phishing, and that's a much bigger revenue stream than a few boring reports. Further, the security model is stagnant at best and a crock at worst, so why not try something new? And, the browser manufacturers aren't playing their part, with narry a one admitting that the problem is in their patch. So their users are also vulnerable to a takeover by someone with some marketing and security sense.

Well done Netcraft, is all I can say! Which is to say that I have no idea whether the plugin itself will work as advertised. But the concept, now, that's grand!

2004 Financial Report of the United States Government - How Big?

Adam's blog pointed me to this description of the switcherooo in US government accounting. In brief, the USG has been using cash accounting, which means they count up the cash coming in, and going out, and that's their profit & loss. Yet, the SEC mandates accrual accounting for all companies of any note. The difference is pretty substantial. In accrual accounting, you also include all your *future* income and liabilities. This of course means that on paper at least you can't play games with this year's numbers at the cost of next year's numbers.

Now, it seems that some rebels in Congress got the US treasury to at least present some rough accrual numbers this year. So we can see the difference. Well, it ain't good. Actually, it's unbelievable. So sit down, and prepare to expire.

On a cash basis the USG has incurred an extra debt of about $412 bullion, for the fiscal year of 2004. But, on an accruals basis, the number is $11.087 trillion dollars.

That's twenty seven times bigger than the popular, published number, if these numbers are to be believed. Can you say Enron on a global economic scale?

See the post, and the UST's hopefully authoritive report for the details. I can't cope, but luckily I don't need to. All you American Accountants out there.... It's over to you: Tell Mr Scrivener he's wrong! You owe it to your country.

The Guru Code - a great technique for something that never happens!

A hand-me-down copy of ACM Queue has an article in it about "the Guru Code" which lambasts this allegedly poor behaviour by programmers. The author was a bit flustered by seeing

Fatal System Error
Guru Code: #0002000436; #0001000258

on his TV screen.

Certainly, it's bad for a member of the user public to be exposed to this stuff. But, consider the lot of the poor programmer: no confidence in design, no patience in re-work, desperation to get the demo out, the impending doom of managerial dictat to distribute the demo, the creep of featurism, tuning into the flood of complexity ...

Huge amounts of code gets written in a rush to trial it and then either sent out as finished work, or thrown away. There's no middle ground, many times. To respond, the embattled programmer evolves. Learning, hacking, proving, grand construction, re-construction, managerialism, revisionism, and hacking all over again.

As we travel this path from initiate to guru and back to code monkey, we develop techniques of survival. One of the most efficacious is what the article refers to as the Guru Code. This is an indecipherable number that is only interpretable by the person who wrote it. What this means is that a particular path of code that should never have happened has indeed happened.

Of course, the outsider can say, well, you should write better code. Nope, see above; the boss wouldn't let that happen. Or, at least, you should write better error messages. Which is what the article states.

Think about it for a bit. If the code should never have happened, that means that it wasn't going to be dealt with in code! What would the error message say? "Write me?" Or, perhaps, "tell my boss I told you so?"

In practice there are lots and lots - we are talking in the thousands here for any serious shipped product - of error conditions where there is nothing to say. Other than it happened right here, and that's something that should never have happened.

What I tend to do is put in a "numberplate" error code. This little innovation is a group of three letters and three digits: ABC123, chosen randomly by typing blind. Then, if it *ever* pops up in a user complaint or a log, it is recognisable as such. The only solution is to run a massive search of all source code looking for it, and go looking at the code (there is no support database for these things, because they never happen).

Of course, such a non-occurrance happens only once a year or so. Like the front cover of the magazine says, "System Errors Happen. Deal with it." When it does happen, it's really useful to see the code stick out like a sore thumb. From there, inspection of the code makes it clear, and we can make some minor fixes to get back to the normal state of affairs, which is that it will never ever happen (again). Promise.

FC'05 programme - announced

Stuart Schechter sent out the FC05 programme announcement just now, and it includes a text version of the programme, so here it is. The programme looks pretty good this year, with some varied stuff away from the "pure crypto" legacy of prior FC conferences.

For those who don't know, FC is a fun conference, with a lot of 'beach time' due to the locations. Good mixing opportunities are had by all.

---

The program and preliminary schedule can be found at:
http://www.ifca.ai/fc05/program.html

An official call for participation will be sent out as soon as
registration is open. (We expect this to be early next week.)

If you've yet to make travel arrangements, I would encourage you to stay
in Dominica on Thursday night (3/3) or longer to avoid a rush to the airport
after the morning program. In the past, attendees who have stayed after the
conference have found that this is an excellent time to meet with others.

Keynote Speakers
================

Lynne Coventry (NCR)
Bezalel Gavish (Southern Methodist University)

Panel Sessions
==============

Financial Technology in the Developing World
Allan Friedman (Harvard) - Organizer
Alessandro Acquisti (CMU)
H William Burdett, Jr. (Foley & Lardner, LLP)
Jon Peha (CMU)

Phishing
Steve Myers (Indiana University) - Organizer
Drew Dean (SRI)
Stuart Stubblebine (Stubblebine Research Labs)
Richard Clayton (Cambridge, UK)
Markus Jakobsson (Indiana University CACR)

Research Papers
===============

Fraud within Asymmetric Multi-Hop Cellular Networks
Gildas Avoine (EPFL, Lausanne, Switzerland)

Information-Theoretic Security Analysis of Physical Uncloneable Functions
P. Tuyls
B. Skoric
S. Stallinga
A.H. Akkermans
W. Ophey (Philips Research Laboratories, The Netherlands)

Views, Reactions and Impact of Digitally-Signed Mail in e-Commerce.
Simson L. Garfinkel
Jeffrey I. Schiller
Erik Nordlander (MIT)
David Margrave (Amazon.com)
Robert C. Miller (MIT)

Identity-based Partial Message Recovery Signatures
(or How to Shorten ID-based Signatures)
Fangguo Zhang (Sun Yat Sen University, P.R.China)
Yi Mu
Willy Susilo (University of Wollongong, Australia)

How to Non-Interactively Update a Secret
Eujin Goh (Stanford University)
Philippe Golle (Palo Alto Research Center)

Interactive Diffie-Hellman Assumptions with Applications
to Password-Based Authentication
Michel Abdalla
David Pointcheval (Ecole Normale Superieure)

Achieving Fairness in Private Contract Negotiation
Keith Frikken
Mikhail Atallah (Purdue University)

Protecting Secret Data from Insider Attacks
David Dagon
Wenke Lee
Richard Lipton (Georgia Tech)

RFID Traceability A Multilayer Problem
Gildas Avoine
Philippe Oechslin (EPFL Lausanne Switzerland)

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

Countering Identity Theft through Digital Uniqueness,
Location Cross-Checking, and Funneling
P.C. van Oorschot (Carleton University)
S. Stubblebine (Stubblebine Research Labs)

Policy-Based Cryptography and Applications
Walid Bagga
Refik Molva (Eurecom)

A Privacy Protecting Coupon System
Liqun Chen (HP Laboratories)
Matthias Enzmann (Fraunhofer SIT)
Ahmad-Reza Sadeghi (University of Bochum)
Markus Schneider (Fraunhofer SIT)
Michael Steiner (IBM T.J. Watson)

Analysis of a Multi-Party Fair Exchange Protocol and Formal
Proof of Correctness in the Strand Space model
Steve Kremer
Aybek Mukhamedov
Eike Ritter (University of Birmingham, UK)

Secure Biometric Authentication for Weak Computational Devices
Mikhail J. Atallah
Keith B. Frikken (Purdue)
Michael T. Goodrich (UC Irvine)
Roberto Tamassia (Brown)

Small Coalitions Cannot Manipulate Voting
Edith Elkind (Princeton University)
Helger Lipmaa (Helsinki University of Technology)

Efficient Privacy-Preserving Protocols for Multi-Unit Auctions
Felix Brandt (Stanford)
Tuomas Sandholm (Carnegie Mellon University)

Risk Assurance for Hedge Funds using Zero Knowledge Proofs
Michael Szydlo (RSA Security/Independent)

Testing Disjointness of Private Datasets
Aggelos Kiayias (University of Connecticut)
Antonina Mitrofanova (Rutgers University)

Time Capsule Signature
Yevgeniy Dodis (NYU)
Dae Hyun Yum (POSTECH)

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

Approximation in Message Authentication
Giovanni Di Crescenzo
Richard Graveman (Telcordia)
Gonzalo Arce
Renwei Ge (U Delaware)

Systems & Applications Presentations
====================================

Securing Sensitive Data with the Ingrian DataSecure Platform
Andrew Koyfman (Ingrian Networks)

Ciphire Mail Email Encryption
Lars Eilebrecht (Ciphire Labs)

STORK - strategic roadmap for crypto - New Trends in Cryptology

Phong Nguyen has edited for STORK a long 'New Trends' discussion of what cryptologers are concentrating on at the moment. It's very much a core, focused scientists view, and engineers in the field will find it somewhat disjoint from the practical problems being faced in applications today. E.g., no mention of economic or opportunistic models. Still for all that, it is a useful update on a broad range of areas for the heavy crypto people.

New Trends in Cryptology (PDF only?)

New job quiz: what's this post mean then?

A lot of discussions have been circulating about how to separate out the good guys who know stuff from the chaff that talks the talk but can't walk, even before the google cats test circulated. I recently figured out a great test for any payment systems person. Hand the prospective engineer any relevant post as written by Lynn Wheeler (and Anne, allegedly) and ask the candidate to explain it. If they can, hire them because they've obviously done enough to see what he's on about! If they can't, scratch that candidate, as they haven't got that "been there, done that" track record.

But, even better, I came across this little gem buried deep in one prospective employment exam. I'm not sure how to use this, yet, but I'm thinking on it.... Comments welcome!

Anne & Lynn Wheeler writes:

[huge snip...]

a little tale out of school. after the initial encrypting modem testings, all products from the company with phone jacks had deeply recessed contacts. one of the first testers for this home/travel/hotel encrypting modem was a corporate VP ... who apparently had been an EE in some prior lifetime. He was trying to test out the modem and stuck his tongue on the contacts to see if there was any current. unfortunately, the phone decided to ring at that moment. the result was an edict that all phone jack contacts had to be recessed so that people (especially corporate VPs) were unable to touch them with their tongue.

User education: worse than useless

Cypherpunk askes a) why has phishing gone beyond "don't click that link" and b) why we can't educate the users?

A lot of what I wrote in The Year of the Snail is apropos to that first question. In economic terms, we would say that Phishing is now institutionalised. In more general parlance, and in criminal terms, it would be better expressed as organised crime. Phishing is now a factory approach, if you like, with lots of different phases, and different actors all working together. Which is to say that it is now very serious, it's not a simple net bug like viruses or spam, and that generally means telling people to avoid it will be inadequate.

We can look at the second question much more scientifically. The notion of teaching people not to click has been tried for so long now that we have a lot of experience just how effective the approach of 'user education' is. For example, see the research by Ye and Smith and also Herzberg and Gbara, who tested users in user interface security questions. Bottom line: education is worse than useless.

Users defy every effort to be educated. They use common sense and their own eyes: and they click a link that has been sent to them. If they didn't do that, then we wouldn't have all these darn viruses and all this phishing! But viruses spread, and users get phished, so we know that they don't follow any instructions that we might give them.

So why does this silly notion of user education persist? Why is every security expert out there recommending that 'users be educated' with not the least blush of embarrassment at the inadequacy of their words?

I think it's a case of complexity, feedback and some fairly normal cognitive dissonance. It tends to work like this: a security expert obviously receives his training from some place, which we'll call received wisdom. Let's call him Trent, because he is trusted. He then goes out and employs this wisdom on users. Our user, Alice, hears the words of "don't click that link" and because of the presence of Trent, our trusted teacher, she decides to follow this advice.

Then, Alice goes out into the world and ... well, does productive work, something us Internet geeks know very little about. In her office every day she dutifully does not click, until she notices two thing. Firstly, everyone else is clicking away like mad, and indeed sending lots of Word documents and photos of kids and those corny jokes that swill around the office environment.

And, secondly, she notices that nobody else seems to suffer. So she starts clicking and enjoying the life that Microsoft taught her: this stuff is good, click here to see my special message. It all becomes a blur and some time later she has totally forgotten *why* she shouldn't click, and cannot work out what the problem is anyway.

(Then of course a virus sweeps the whole office into the seas ...)

So what's going on here? Well, several factors.

1. Trent successfully educated Alice. So he runs around with the notion that user education is a fine tool and it works A-OK! Yes, he believes that we can achieve results this way. He promotes user education as the answer to our security needs.
2. Alice more or less left her education session successfully educated. But it doesn't last, because everyone else doesn't do it, and she can't see the sense in it anyway. That is to say, in systems theory, Alice cannot close the loop. She cannot see the action she is asked for as causing any additional security. As there is no reinforcing feedback, after a while it breaks, and never gets renewed.
3. Trent only managed to impress a small group of users. The vast majority of users out there however are 'the masses'. Many people don't actually know any computer experts, and they go into a retail store like Walmart to buy their computer. They have enough trouble coping with the fact that the parts need to be connected together in order to work ... and esoteric notions of clicks and security and viruses just go right over their heads.
4. When a virus or other plague like phishing does sweep through and wash the users into the sea, it's very unclear who to blame. Was it the bank? Was it Microsoft? Was it Sally-Anne who clicked on too many links? Or the Simon the systems administrator who installed a new Virus filter? Or, maybe it was Hamisch the terrible eastern European hacker again? Or ... , or ..... Just exactly why it happens is totally difficult to determine, and *that* means that the distance between the crime and any adequate defences is so great that there is no real feedback to reinforce the defences. Why defend when it is not doing anything?
5. If only a small subset of users are 'educated' this achieves nothing other than the minor effect of them potentially being protected. That's because if a virus sweeps through, we all suffer, even if we have protected ourselves. Yet, to stop the virus, we *all* have to follow the discipline. So we have a sort of free-rider problem: we have no way to make sure that all the users are 'educated' and thus there is no real incentive for anyone to educate.
6. Getting back to Trent, of course, he is secure. Everyone reading this blog is secure. Unless they are real users, in which case they didn't understand a word of it and didn't get this far (sorry about that!). So for Trent and our sort of person, we don't see the problem because it doesn't directly effect us. We are shut off from the real world of users.

Hence, cognitive dissonance. In this case, the security industry has an unfounded view that education is a critical component of a security system. Out in the real world, though, that doesn't happen. Not only doesn't the education happen, but when it does happen, it isn't effective.

Perhaps a better way to look at this is to use Microsoft as a barometer. What they do is generally what the user asks for. The user wants to click on mail coming in, so that's what Microsoft gives them, regardless of the wider consequences.

And, the user does not want to be educated, so eventually, Microsoft took away that awful bloody paperclip. Which leaves us with the lesson of inbuilt, intiutive, as-delivered security. If you want a system to be secure, you have to build it so that it is so intiutively to the user. Each obvious action should be secure. And you have to deliver it so that it operates out of the box, securely. (Mozilla have recently made some important steps in this direction by establishing a policy of delivery to the average user. It's a first welcome step which will eventually lead them to delivering a secure browser.)

If these steps aren't taken, then it doesn't help to say to the user, don't click there. Which brings me to the last point: why is user education *worse* than useless? Well, every time a so-called security expert calls for the users to be educated, he is avoiding the real problems, and he is shifting the blame away from the software to the users. In this sense, he is the problem, and until we can get him out of the way, we can't start thinking of the solutions.

Nyms sighted in authentication software

The use of the nym is seeing a little bit of a revival, driven by the onslaught of chat as the future means of communication for anyone under 30. Over on Adam's more prolific blog there is word of a company called WikID that is pushing nyms from phones.

A short explanation of the cryptographic nym as a rights technique. A public/private key pair is created, and the public key is registered with a server. The private key is kept private! Now that arrangement can be used for the private key holder to authentice, or sign for, any action so permitted in the software. (You can also simulate the thing with a name and a password, which is good enough as long as there is no serious value involved.)

Nyms are identities. They are not like IDentities, the ones that politicians assure us we'd be better off if we had more of. Nyms are instead short lived, light weight identities that allow one action to relate to another. That is, if you used a nym to chat with some dude today, and also tomorrow, he would be no trouble relating the two as the same person. Bob recognises Alice from a couple of days ago, by the light touch of her nym.

Cryptographically, these are real strong. But they are also creatable on demand; making one of these things takes ... oh, seconds of otherwise wasted CPU time. Good nymous software makes them on demand and lets the users dictate what to do with them. Nyms are very very powerful, and can be used for chat, payments, trades and the like, as long as the designer recognises their asset characteristics. It is only the accident of the less powerful but more IDentifying Certificate Authority model that secures only a tiny part of the security needs of ecommerce that has overshadowed nyms in popular software.

Nyms can also be dumbed down and turned into singular authentication tokens, like certs in the CA model, and this seems what the WikID company has done. They have a client that downloads and installs on a phone or PDA, and creates a nym for purposes of gaining entry to a web site or other server asset.

Any exposure for the concept would be good, so I wish them well. It's been a hard lonely road for us nym developers for the last decade or so.

Security Coding Best Practices - Java adds yet another little check, and boom...

Over on Adam's blog he has a developing theme on 'security signalling.' He asks whether a code-checking program like RATS would signal to the world that a product is a good secure product? It's an important question, and if you need a reason, consider this: when/if Microsoft gets done rewriting its current poisoned chalice of an operating system, how is it going to tell the world that it's done the job?

Last night I had occasion to feel the wrath of such a check, so can now respond with at least one sample point. The story starts earlier in the week, when I reinstalled my laptop with FreeBSD 5.3. This was quite a massive change for me, up from 4.9 which had slowly been dying under the imposition of too many forward-compatible ports. It also of course retriggered a reinstall of languages, but this should have been no trouble as I already had jdk1.4.2 installed, and that was still the current. (Well, I say no trouble ... as Java is "unsupported" on FreeBSD, mostly because of Sun's control freak policies creating a "write once, run twice" environment.)

Anyway, my code went crazy (*). A minor change in the compiler checking brought out a squillion errors. Four hours later, and I'd edited about 100 files and changed about 500 lines of code. My eyes were glazed, my brain frizzled and the only cognitive capability I had left was to open beers and dispose of them.

Now, this morning, I can look at the effect, hopefully in the cold hard light of a northern winter's sunny day. At least for another hour.

It's security code (hard crypto payments) so am I more secure? No. Probably actually less secure, because the changes were so many and so trivial that the robot masquerading as me made them without thinking; just trying to get the darn thing to compile so I could get back to my life.

So one answer to whether the RATS proposal could make any difference is that it could make things worse: If thrown at a project, the rush to get the RATS thing to come out clean could cause more harm than good.

Which is a once-off effect or a singularity. But what if you didn't have a singularity, and you instead just had "good coding checks" all the time?

Well. This is just like the old days of C where some shops used Lint and others didn't. (Lint was an old tool for cleaning out "fluff" from your C code.) Unfortunately there wasn't enough of a real discernable difference that I ever saw to be able to conclude that a Lint-using shop was more secure.

What one could tell is that the Lint-using shop had some coding practices in place. Were they good practices? Sometimes, yes. Maybe. On the whole Lint did good stuff, but it also did some stupid things, and the net result was that either you used Lint or you were careful, and not using Lint was either a signal that you were careful and knew more, or you weren't careful, and knew less; whereas using Lint was a signal that you didn't know enough to be careful, but at least you knew that!

We could debate for years on which is better.

As an example of this, at a tender age, I rewrote the infamous strcpy(3) set of routines to eliminate buffer overflows. Doing so cost me a day or two of coding. But from there on in, I never had a buffer overflow, and my code was easy to audit. Massive benefit, and I preferred that to using Lint, simply because *I* knew what I was doing was much safer.

But how to convince the world of that? I don't know ... still an open question. But, I'm glad Adam has brought up the question, and I have the chance to say "that won't work," because the answer is probably worth an extra percentage point on Microsoft's market cap, in a couple of years, maybe.

---

* The code is WebFunds which is about 100kloc (kilo-lines-of-code) chock full of hard crypto, RTGS payments and various other financial cryptography applications like secure net storage and secure chat.

Mexico flirts with the silver unit - a good base for digital issuance

One sees more and more references to Islamic countries musing on gold as their base for currency; but also silver might shine again. Mexico is delving into her historical consciousness for some semblance of honesty in money.

Whether this ever gets further along than a popular movement is unclear, but certainly the populace seems to like the idea, if an essay by Hugo Salinasthat is circulating the net is any guide (or here or here; the original spanish seems lost!). So much so that the Bank of Mexico allegedly felt the need to defend its own paper unit.

People outside financial cryptography often get bemused by the concentration on precious metals. When outsiders see Issuers using those tired barbaric relics for currencies, they find it too easy to write off the field. What they miss needs some explanation and with Mexico's flirtation, now seems to be as good a time as any to explain.

It's fundamentally a consequnce of open governance. To see that consequence, let's review how open governance works. For those familiar, skip these paragraphs...

The core of issuance is about presenting a contract of value. It could be any value, really, and it is only the imagination of the Issuer that is the limit here. Currencies are one such, first proposed by David Chaum, but also financial instruments such as shares, bonds and options are equally issuable.

Virtual issues were obvious from the very first days: loyalty systems, gaming units, gambling chips and the like were readily recognised as issuable, and there have been many proposals in this vein since Chaum first kick started the field with his blinding formula.

---

Which all leads to a very tricky problem: if it is so easy to issue loyalty points and so easy to issue currency, how does a confused public tell the difference?

Enter, for the first part, the contract. The agreement between the Issuer and the users is called a contract, and in that document it should say what the issue is. Currency, loyalty, casino chips, or options on futures of first sons; it's all written in the agreement.

But, the canny and suspicious public says, those are just words! How do we know that the Issuer will keep his word [1]?

Enter for the second part, the five parties model. In the 5PM as it is abbreviated, reserves can be allocated and stored with one party that is independent of the Issuer. This would be an escrow partner or a trustee. Then, a second party becomes a co-signatory, whos signature is required to release any assets. Thirdly, the Issuer appoints a manager to day to day deals, with a small float, so the Issuer himself is separated from the business aspects. That makes for four parties, all watching each other.

And finally we enroll the public as the fifth party. She is coopted into auditing all the activities of the other parties. So the 4 insider parties publish their activities and also the status of the reserves at any one time, and the user keeps an eye on all those things.

The 5PM reduces the issuance of value to a process and to an accounting mechanism. We have reduced the safety of an issuance to a problem of no more difficulty than counting. We've swept away all that nonsense and cost called Basel II, Sarbanes Oxley and other disasters of governance, and put the user firmly in charge.

All she has to do is count [2].

And this is where precious metals like gold and silver step in. Metal is easy to count. It is either here or it is not. The bars are either in the vault or they are not. Any member of the public can cope with that question.

In contrast, every other base for issuance is more complicated. Are there dollars in your account? Where is the wire that was sent last month? Have my airmiles been credited, and are they really there if I cannot buy the flight I want? Am I a shareholder in full ownership of these shares, and what's this about the shares having been lent out? Can you explain the theft of mutual funds again, but really slowly this time [3]?

The problems with virtual issues like currency, shares, bonds, etc etc, go on and on. Physical metal however is tractable. It stops right here: is there a bar or is there not?

Which means that by far the most efficient thing to issue in a digital world, in the context of governance, is precious metals. It's efficient in the sense that a very small team can create a very powerful governance model and present an honest issue to their user community. Hence, startups look closely at the relic, and see not barbarity, but governability.

So Mexico's move is good news for digital issuance. The more the silver and gold gain respect, the more users there are for a simple, robust digital issue. And the more we have a firm base in precious metals, the more issuers can get into the complicated stuff like dollars, mutual funds and shares, and provide those with the open governance that users expect. Go Mexico!

---

Images are from Mobile Silver. For more interest in coins, see Austria issues 100,000 Euro coin

[1] In financial cryptography, the Issuer is masculine, and the user is feminine. This cryptographic custom uses a trick of the english language, and may or may not make any sense in other languages.

[2] Just to cap off this quick description of the 5PM: we now have sufficient empirical evidence that it works.

[3] These are all real, today complaints, well beyond the ken of the user. Mutual funds in the US were raided in a complex scam by insiders that stole more value than we care to write down. And for shares, there is a complex scam alleged in courts where the manager of the shares, DTCC, was claimed to have lent out the shares without limit to those shorting the stock, again without limit.

Email is dying ... Stats from Postini

Whenever I see more evidence that Email is dying, the John Lennon refrain of "War is over" pops into my head. There must be some art in this. Anyway, here's two pieces of evidence: you will get this email TWICE - I'm sorry about that, let me know if you want unsubscribed, but MT for some reason has decided to double send the emails.

The second piece of evidence is more supporting of the thesis that email is dying. Postini, a mail applications and spam filter provider company, has released some stats on the year according to spam. The headlines: last year (2003) 22% of emails were legitimate. This year that number is down to 12%, and next year, 2005, Postini predicts that only 8% of emails will be legit.

For me the number is more like 5%, so I'd be happy with that :) But, joking aside, it lends credence to the notion that email is becoming more expensive than it is worth. Young people already have ditched it, and older people are also learning the joys of phones, chat, blogs and other ways to stay in touch. Which is good, as email has proven to be an archaic tool over which to do business. FC applications much prefer chat and phones. So say I, at least.

Oh, and Postini also said that virus-infected mails have exploded: 2003 had an average of one in 200, and towards the end of this year they saw 1 in 25! Hard numbers for those who think this is a passing phase.

"Email is dying ... War is over ..." I wish I knew what song that was.

http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/12-15-2004/0002634215&EDATE=

---

Addendum, further evidence from Fm is this Korean article on the new generation not using email.

JP spotted this this article. If you can ignore the American superiority complex (common in popularist american writings), it includes some good stuff about how the blogs are spreading into areas desperate for communication.

2006, and beyond...

Over at EmergentChaos, Adam asked what happens when "the Snail" gets 10x worse? I need several cups of coffee to work that one out! My first impressions were that ... well, it gets worse, dunnit! which is just an excuse for not thinking about the question.

OK, so gallons of coffee and a week later, what is the natural break on the shift in the security marketplace? This is a systems theory (or "systemics" as it is known) question. Hereafter follows a rant on where it might go.

(Unfortunately, it's a bit shambolic. Sorry about that.)

A lot of ordinary users (right now) are investigating ways to limit their involvement with Windows due to repeated disasters with their PCs. This is the the first limiting factor on the damage: as people stop using PCs on a casual basis, they switch to using them on a "must use" basis.

(Downloading Firefox is the easy fix and I'll say no more about it.) Some of those - retail users - will switch to Macs, and we can guess that Mac might well double its market share over the next couple of years. A lot of others - development users and poorer/developing countries - will switch to the open source Unix alternates like Linux/BSD. So those guys will have a few good years of steady growth too.

Microsoft will withdraw from the weaker marketplaces. So we have already seen them pull out of supporting older versions, and we will see them back off from trying to fight Firefox too hard (they can always win that back later on). But it will maintain its core. It will fight tooth and nail to protect two things: the Office products, and the basic windows platform.

To do that, the bottom line is that they probably need to rewrite large chunks of their stuff. Hence the need to withdraw from marginal areas in order to concentrate on protecting that which is core, so as to concentrate efforts. So we'll see a period characterised by no growth or negative growth by Microsoft, during which the alternates will reach a stable significant percentage. But, Microsoft will come back, and this time with a more secure platform. My guess is that it will take them 2 years, but that's because everything of that size takes that long.

(Note that this negative market growth will be accompanied by an increase in revenues for Microsoft as companies are forced to upgrade to the latest releases in order to maintain some semblance of security. This is the perversity known as the cash cow: as the life cycle ends, the cash goes up.)

I'd go out on a limb here and predict that in 2 years, Microsoft will still control about half of the desk top market, down from about 90% today.

There are alternates outside the "PC" mold. More people will move to PDAs/cellular/mobile phones for smaller apps like contact and communications. Pushing this move also is the effect we've all wondered about for a decade now: spam. As spam grows and grows, email becomes worse and worse. Already there is a generation of Internet users that simply do not use email: the teenagers. They are chat users and phone users.

It's no longer the grannies who don't use email, it is now the middle aged tech groupies (us) who are feeling more and more isolated. Email is dying. Or, at least, it is going the way of the telegram, that slow clunky way in which we send rare messages like birthday, wedding and funderal notices. People who sell email-based product rarely agree with this, but I see it on every wall that has writing on it [1] [2].

But, I hear you say, chat and phones are also subject to all of the same attacks that are going to do Microsoft and the Internet so much damage! Yes, it's true, they are subject to those attacks, but they are not going to be damaged in the same way. There are two reasons for this.

Chat users are much much more comfortable with many many identities. In the world of instant messaging, Nyms are king and queen and all the other members of the royal family at the same time. The same goes for the mobile phone world; there has been a seismic shift in that world over to prepaid billing, which also means that an identity that is duff or a phone that is duff can simply be disposed of, and a new one set up. Some people I know go through phones and SIMs on a monthly basis.

Further, unlike email, there are multiple competing systems for both the phone platform and the IM platform, so we have a competition of technologies. We never had that in email, because we had one standard and nobody really cared to compete; but this time, as hackers hit, different technologies can experiment with different solutions to the cracks in different ways. The one that wins will attract a few percentage points of market share until the solution is copied. So the result of this is that the much lauded standardisation of email and the lack of competition in its basic technical operability is one of the things that will eventually kill it off.

In summary so far; email is dying, chat is king, queen, and anyone you want to be, and your mobile/cellular is your pre-paid primary communications and management device.

What else? Well, those who want email will have to pay *more* for it, because they will be the shrinking few who consume all the bandwidth with their spam. Also, the p2p space will save us from the identity crisis by inventing the next wave of commerce based on the nym. Which means that we can write off the Hollywood block buster for now.

Shambolic, isn't it!

[1] "Scammers Exploit DomainKeys Anti-phishing Weapon"
http://story.news.yahoo.com/news?tmpl=story2&u=/zd/20041129/tc_zd/139951
[2] "Will 2005 be the year of the unanswered e-mail message?"
http://www.iht.com/bin/print_ipub.php?file=/articles/2004/12/06/business/netfraud.html

Engineering for Failure

An interview with Bruce Lindsay, one of the core designers of relational technologies, claims it is all about errors. A lot of good observations about the practical side of software engineering; if you've travelled that path, you'll recognise the "shady" practices that might be better off called "best" practices.

Yes, that's about the sum of it. Reliable code is code that deals with errors. If there were no errors, my gut feeling is that we could do this whole thing without about 10% of the code we currently use.

2005 - The Year of the Snail

So if 2004 depressingly swims past us as the Year of the Phish, what then will 2005 bring?

Worse, much worse. The issue is this: during the last 12 months, the Internet security landscape changed dramatically. A number of known, theoretical threats surfaced, became real, and became institutionalised. Here's a quick summary:

1. Viruses started to do more than just replicate and destroy: they started to steal. The first viruses that scanned for valuable information surfaced, and the first that installed keyloggers that targetted specific websites and banking passwords. Just this week, the first attack on the root list of SSL browsers was being tracked by security firms.
2. Money started to be made in serious amounts in phishing. This then fed into other areas, as phishers *invested* their ill gotten gains, which led to the next development:
3. Phishers started to use other techniques to gather their victims: viruses were used to harvest nodes for spam that were used to launch phishing attacks. Integration across all the potential threats was now a reality.
4. DDOS, which seemed to seriously take off in 2002, became a serious *extortion* threat to larger companies in 2004. Companies that had something to lose, lost.
5. In 2004, it now became clear that we were no longer dealing with a bunch of isolated hackers who were doing the crack as much to impress each other as to exercise their own skills. There is now a market phase for every conceivable tool out there, and mere hackers do not purchase the factors of their production.
6. Malware, spyware, and any other sort of ware turned up as infesting average PCs with Windows at numbers quoted as 30 per machine. And this was just the mild and benign stuff that reported your every browse for marketing purposes.
7. Microsoft were shown to be powerless to stem the tide. Their SP2 mid-life update caused as many problems as it might have solved. No progress was discernable overall, and 2004 might be marked as the year when even the bubble headed IT media started questioning the emporer's nakedness.

How can I summarise the summary in one pithy aphorism? For most intents and purposes, the Internet was secure for Windows users until about 2004. From 2005 onwards, the Internet is not secure for Windows users. Are you depressed, yet?

2005 will be the Year of the Snail. Your machine will move slowly and slipperily to a fate that you can't avoid. The security of the Windows system on which the vast majority of the net depends for its leaf nodes will repeat the imagery of a snail's house. Ever toiling, slithering slowly across the garden with an immense burden on its back, and ever fearful of approaching predator. The snail is quick to retreat into its house, but all to no avail, as that crunching sound announces that your machine just got turned into more phish compost.

I had hoped - foolish, I know - that Firefox and the like would have at least addressed the phishing threat by now. But now we are fighting a two fronts war: phishing attacks the browser's security model and UI, while all the rest attacks the Windows platform.

It's really easy to offer a solution: download Firefox, and buy a Mac. But this is like asking a snail to become a hedgehog; it is simply out of the budget of way too many users to rush out and buy a Mac. Those that can do so, do so!

Those that cannot, prepare for the Year of the Snail. And check in with us in a year's time to see how the two fronts war is going. The good news is that statistically, a few snails always survive to populate the garden for the next year. The bad news is that it will decidedly take more than a year for your house to evolve away from the sound of the crunch.

---

Addendum 30th December: The Independent's Charles Arthur wrote The shape of things to come in 2005, which centrepoints security, but also comments on wider issues.

3rd January 2005: The New Scientist's The year in technology.

2004 - The Year of the Phish

Last year, 2003, was a depressing year. We watched the phishing thing loom and rise, and for the most part, security experts fudged, denied, shuffled and ignored while the phish was reeled in. Now, 2004 can truly be said to be the Year of the Phish.

There is progress. Firefox have added two small but nice additions to their browser to address phishing. If you download Firefox (and if you haven't yet, you are now classified as too insecure to be permitted to browse) you can see these when you go to your banking site. On the bottom right, there is a little box containing the domain that is seen by the browser. Also, notice how the URL bar changes colour.

Get used to these things, as they are about the only things protecting you from phishing.

More is needed, however, much much more. Whilst I am somewhat ecstatic that Mozilla programmers have started on this journey, the amount done so far is dwarfed by what would be required to fully address phishing in the browser, and no other manufacturer of browsers seems to have even woken up yet.

(Just briefly, the Certificate Authority needs to be shown. Further, the cert needs to "tracked" by the browser, and a relationship built up. I've suggested a usage count - 100 times to this site, you must like it! Amir and Ahmad have suggested that the user sign off on the cert and even coded it up as Trustbar, while Tyler has suggested the use of petnames for the user's idea of what each site is. They all have their purposes and benefits, and a solution that used all of these and more would be very powerful against phishing. Oh, and all this needs to be "in the face" and not discretely hidden down in some forgotten corner.)

Most of this was known in 2003, by one means or another. But even though we have now to all intents and purposes had a full year of devastating losses due to phishing (more money lost than was ever spent on SSL certs) we still can't say with any degree of confidence that people understand that the browser is being attacked and the browser is where the defences should be placed.

---

Addendum 2004-12-23: John Leyden wrote this 2004 security review for The Register which echoes a similar message.
Also, In 2005, Organized Crime Will Back Phishers we can take as an echo, given that we already saw it in 2004!

Addendum 2005-09-03; new paper on The Economy of Phishing.