After years of thought and days of hacking, Zooko and I have put together a new crypto protocol: Secure Datagram Protocol #1 or SDP1 . It provides for encrypting and MACing a single datagram, within a previously established secret key context.
The sexy details: The inner layer of plaintext is a Pad and a Payload, where the Pad expands to block, as well as incorporating nonce, time and random elements in order to make a good IV. The plaintext is then encrypted with AES128 in CBC mode. A token is prepended to the ciphertext so that receivers can determine where to find the keys, and the whole lot is MACed with HMAC-SHA1. The token, the ciphertext and the MAC then form the on-the-wire datagram.
I have implemented SDP1 in Java and am in the process of using it to create secure back-channels from server-to-client comms within SOX (this is a major mod to the basic paradigm of public key nymous cryptosystems which are normally all client-to-server oriented). Secret sharing was a breeze, and is already done, but usage in a full cryptosuite is much more work!
As SDP1 is intended to be used for financial applications, and is thus datagram oriented, we can't really make use of the many other protocols that have been developed, such as SSL and SSH. In fact, it seems as if there is a bit of a hole in the market for datagram products; I found ESP which has too much of a relationship to IP, and is also a little old, but little else in this area. Architecturally, SDP1 relates quite closely to ESP, but in detail it is different.
Any comments are welcome! The SDP1 docs are reasonably fullsome, but still need some touching up. The entire layout is subject to change, at least until we get to the point of deploying too many nodes to change. At that point, we'll freeze SDP1 in whatever state and plan on a redesign called SDP2.
More from The Register! A man has chosen to use identity biometrics to block fraudsters. He's done this by putting a "Correction" notice into his credit report, thus alerting potential credit suppliers to his imposed condition: get a thumprint. How elegant, how innovative :)
DIY fingerprint idea thwarts ID thieves
By John Leyden
Published Wednesday 24th November 2004 07:59 GMT
The Home Office is touting ID cards as a solution to ID theft in today's Queen's Speech but a Yorkshire man has taken matters into his own hands. Jamie Jameson, a civil servant from Scarborough in North Yorkshire, insists that credit can only be extended in his name on production of a thumbprint.
Jameson hit on the idea of writing to the UK's three main credit reference agencies - Equifax, Experian and Call Credit - and requesting that they put a 'Notice of Correction' on his file stating that a print must be offered with applications for loans or credit cards issued in his name. At the same time he submitted his fingerprint.
This Notice of Correction of the first thing a prospective lender will see when it calls up his records. Normally this facility provides a way for individuals to explain why they have a county court judgement against their name or other qualifications to their credit history. Jameson is using it to do a cheap security check.
Although uncommon in the UK, thumbprints are often used as an audit mechanism for people cashing cheques in US banks. A similar scheme was trialled in Wales. Jameson takes a little ink pad similar to that used in US banks around with him all the time just in case he might need it.
If an application for credit is accepted without a thumbprint - against Jameson's express instructions - then he will not be liable for losses. If a would-be fraudster gives a false print on an application then it makes it easier for them to be traced by the police. "Lenders don?t have to match prints. Using prints just establishes an audit trail if anything goes wrong," Jameson explained. "It's not so much me proving who I am as preventing someone else being me."
Jameson has been using the idea successfully for over a year. He concedes that the scheme isn't foolproof and that it's possible to fake fingerprints ("nothing?s perfect," as he puts it). As far as Jameson knows he's the only person who's using the technique in the UK. The scheme delays the issuing of credit, which could be a problem with people who apply for multiple accounts but this is a minor inconvenience for Jameson. "This is driven by the individual so there are no data protection issues. It's a real deterrent to ID theft," he told El Reg. ®
Over on the Register they are reporting on a rebellion - they called it a strike - by eBay's users in Spain. Initially, this just seemed to be a bunch of grumbling spaniards, but the rebellion quickly spread to other countries. What seems striking to me is that Spaniards are not the grumbling kind, so things must be pretty bad out there.
It's fun reading! Reading between those lines, it all comes down to the business model goal of pandering to features. Back in the early days of building systems, the architect is faced with a very heavy choice: features or cost. It's generally an either/or, and for the most part features wins in the market place and features wins in the mind space.
A brief explanation of the problem space. When you build a feature that is transactional in intent, there are three standards it must meet, one after the other. Demonstrable, which means you can demo it to your boss, and to analysts, to the extent that they get what it is you are trying to say, and immediately order it into production. Or, if they are analysts, they immediately stock up on options, and then write their Buy recommendations.
Wisely, the developer ignores all that, and then moves the feature to the next standard, which is Usable. This means that under most users and most circumstances the feature actually works. People can bash and bang at it, and any series of 10 user tests makes everyone smile. At this point, even the developer can only smile with joy as his new feature goes into production.
But there is a further standard: Transactional. This means that the feature returns a complete result in every case. It doesn't mean that it always works - that's beyond the ken of mere mortals and most developers. Transactional means that the result that is returned is completely reliable, and can be used to instruct further actions. It is this focus on errors that allows us to get to the real prize for Transactional software: the ability to build other software systems on top.
A few examples: an email is transactional, as you don't ever receive half an email. A bank payment is not, as people are required to find out what happened. A web request can be transactional but a web session is not. That's why there are warnings on some sites "don't push this button twice when buying..."
Most features never make the Transactional standard. Most users don't know it even exists, until they discover their favourite feature doesn't have it. And even then, the mystery just deepens, because nobody says those magic words "oh, the software never made it to Transactional status."
Here's how the progression works:
Firstly, the feature comes into use and it has a lot of bugs. The users are happy enough that they ignore the errors. But then the euphoria dies and the tide of malcontent rises ... then there is a mad push to fix bugs and the easy ones get fixed. But then the bugs get more complex, and each failure involves more and more costs. But by now, also, there are some serious numbers of users involved, and serious numbers of support people, and serious numbers of revenue bux pouring in, and it is no longer clear to the company that there are remaining problems and remaining costs...
So the company institutionalises a system of high support costs, pushing errors back onto compliant users who can be convinced by some convenient reason, and the developers start moving onto other projects. These are all the wrong things to do, but as the user base keeps growing, insiders assume that they are doing something right, not wrong.
As one CEO infamously said, "People keep sending me money." Until they stopped, that is.
To get a full appreciation of what happens next, you have to read Senge's _The Fifth Discipline. His book uses feedback notions to describe how the machine seems to run so well, and then all of a sudden runs full speed into a brick wall. The reason is partly that which worked at user base X won't work at user base 2X, but it's more than that. It's all the factors above, and it can be summed up in one sentance: the failure to move from Usable to Transactional.
You can see this in many successful companies: Microsoft's current security woes are a result of this, they hit the brick wall about 2001, 2002 when the rising tide of virues overtook the falling star of Internet/PC growth. e-gold, a payment system, hit this very problem in 2000 when they went from 10 times annual growth to zilch in a quarter.
On the strength of one article (!) I'd hazard a guess that eBay and Paypal are now entering the phase of running fast and achieving no traction. I.e., the transactional Brick Wall. To be fair, it's a bit more than one article; Paypal have never ever had a transactional approach to their payment system, so it is really been a bit of a mystery to me as to why it has taken so long for their quite horrific hidden cost structure to bite.
According to an unattributed source, the SANS people are looking to compile a list of Sarbanes-Oxley horror stories. They might have their work cut out for them!
For those who don't follow governance like it effects our every minute, Sarbanes-Oxley is the Act in the USA to tighten up the rules on how a company does .. well just about everything. It's the result of the Arthur Andersens, the Worldcoms and other billion dollar collapses. It's big, it's long, it's boring, and if you have heard of it, your only friends are people who have also heard of it...
Notwithstaning its dry accounting background, Sarbanes-Oxley has raised bureaucracy to new levels. Like a scene from Brazil, it's solution to every ill is rules and yet more rules. Understandably, people don't like it, but because it applies to all companies equally, there is little to be gained in fighting it, as it is only the customer who has to pay, and it has no bearing on competing against your competitors, only against your self.
What makes it especially interesting is that this time the risk is entirely within the company; outsourcing of any component is no excuse! A recently seen trend is that new hires in risk management are empowered to develop their own IT teams. Why? Because they can no longer simply shift the burden onto another department; Sarbanes-Oxley requires you to be responsible for the risk, however it's done.
And they're getting tough on compliance. This time, if your company is not up to scratch, you may well be offering yourself up as a sacrifice to a regulatory orgy of fines, inspections, naming and shaming and other terrors.
More great news for suppliers of solutions. More fear, uncertainty and doubt, and less risk. Who could ask for more?
Mini Research Project: Sarbanes Oxley 404 Horror StoriesSANS is looking for evidence to support an assertion we hear a lot, that there is insufficient IT guidance in SOX 404/COSO to show that your IT systems have the needed controls to demonstrate the audit report is accurate. We have heard reports from the field talking about 2 auditors | from the same firm having opposite findings, or more commonly, organizations that can't figure out what to do so they end up buying a six figure SAS 70 to have some sort of coverage. If you have a horror story you can share that would be great, I am happy to read non-attributable statements, but what we are looking for are stories where we can name the individuals and organizations. Send your horror stories to stephen@sans.org
Another day, another threat. Here's the story of an electrician who was caught using a strange device with strange wires inside the electronic bowels of the New York Federal Reserve. Rather than pre-judge this one, I'll put my say in the comments on the site. You be the judge!
http://www.nydailynews.com/front/story/251774p-215484c.html
How a guy's gizmo spread fear at Fed
BY THOMAS ZAMBITO
DAILY NEWS STAFF WRITER
It nearly sparked a financial catastrophe.
An electrician's homemade gadget wreaked havoc on the Federal Reserve Bank of New York, causing computer convulsions at a facility that houses the world's biggest cash vault, the Daily News has learned.
The foulup short-circuited the career of journeyman electrician John Cravetts, who was fired though he insists he meant no harm.
But it could have been much worse, according to papers filed in Manhattan Federal Court.
"The results could have been catastrophic," said Barry Schindler, an attorney for the New York Fed.
Fed officials say they might have had to shut down computers that process some $2.5 trillion in funds and securities payments and $4 billion in checks every day.
Fortunately, backup systems kicked in after the Nov. 17, 2002, incident.
The heavily guarded facility in East Rutherford, N.J., is also home to a vault that handles more than $1 billion in currency, coins and food coupons.
Cravetts, 62, was canned two weeks after the incident. A surveillance tape caught him using the crude device - two red wires strung between an ordinary household switch and plug.
He later filed an age discrimination suit and also charged his firing was retaliation for reporting an electrocution hazard at the facility where he'd worked for almost 10 years.
Manhattan Federal judge Harold Baer tossed out Cravetts' claim this week.
"I had an unblemished record," Cravetts told The News yesterday.
"What I did was in good faith. I did not do anything malicious," added the licensed electrician, who has since found a new job. "What do they think I'm going to do, sabotage it?"
Although Fed attorneys presented a near-doomsday scenario in court filings, Fed spokesman Peter Bakstansky downplayed the incident yesterday.
"There was no point at which the operations of the Fed were in danger," Bakstansky said. "We stopped him. ... We have a lot of redundancy."
Cravetts had been asked to locate circuit breakers on the Fed computers that had not been properly labeled.
He used his gizmo to conduct the search, plugging it in and tripping breakers, knocking out power as he went along.
Cravetts told The News his superiors knew he used the device. He had made four of them at work.
Fed attorneys say he should have used a device that sends a harmless tone back to the breaker and doesn't cause disruptions.
Cravetts said that for more than a year, he had asked his bosses to order the manufactured device needed for the job, but they never did.
Originally published on November 11, 2004
Following on from recent reports that the UK and the US are trialling advanced back-scatter millimetre radar scanners that see through clothing ... comes this story about how school children are defeating security systems to sneak their cell phones into school. See the article below for the basic techniques.
The lesson for those who aren't familiar with security is not what they did, but how they discovered it. Basically, we can guess that the school children tried different measures, discarded those that didn't work, and shared those that did. In other words, a learning attack.
Which, incidentally, we should find quite encouraging, right? After all, that's what school is about.
Getting back to the wider security implications, the question is whether other security systems are secured against attackers who can learn.
========================================
KIDS' SECRET 'CELLS'
By MATTHEW SWEENEY
October 25, 2004 -- Savvy students are figuring out all kinds of ways to get their cellphones past metal-detectors and school-security staff at city high schools, where the devices are banned.
Kids at Martin Luther King Jr. HS on the Upper West Side put the phones behind a belt buckle - and blame the buckle for the beeping metal-detector.
Some girls hide the phones where security guards won't look - in their bras or between their legs.
"You tell them you're wearing an underwire bra," said Gleneshia Jesquith, 17. "What are they going to do, strip us apart for a cellphone?"
"They put the phone in their thighs and they walk in with their legs together through the metal-detector," said Lauree, 16, another MLK student. La Guardia HS, across the street from King, has no metal-detectors, and lets students keep cellphones under what a staffer called an "as long as we don't see it" approach to the city's policy.
"There's a ban, but it's not enforced," said a La Guardia staffer, who declined to give her name.
So La Guardia students keep cellphones off and out of sight, and take advantage of the school's hallway "mood lighting" to make calls from darkened corners.
La Guardia even has an area in the lobby set aside for kids to make emergency calls.
Some approaches don't always work.
"I put my phone in between two pieces of bread and wrapped it in tin foil," said Lauren Nocco, 15, a sophomore at James Madison HS in Brooklyn.
The school took away her phone - and won't give it back until a parent retrieves it.
Mom-and-pop businesses near schools are getting more traffic from the ban.
Madison Deli, near James Madison HS, stores kids' cellphones in labeled paper bags behind the counter while they're in school. When school's out, kids surge into the deli to pick up their phones - and buy drinks and snacks.
The owner, Timothy Thompson, doesn't charge for the phone-storage service - but he does require the kids to bring in their own self-labeled paper bags.
"This is a good school," Thompson said. "They're good kids. Without them, we wouldn't be here."
In surprise and indeed shock, someone has made smart card identity systems work on a national scale: The Estonians. Last week, I attended Conult Hyperion's rather good Digital Identity forum where I heard the details from one of their techies.
There are 1.35 million Estonians, and they hold an issued 650,000 cards. Each card carries the normal personal data, a nationally established email address, a photo, and two private keys. One key is useful for identification, and the other is used for signing.
Did I say signing? Yes, indeed, there is a separate key there for signing purposes. They sign all sorts of things, right up to wills, which are regularly excluded from other countries' lists of valid uses, and they seem to have achieved this fairy tale result by ensuring that the public sector is obliged to accept documents so signed.
I can now stop bemoaning that there are no other extant signatory uses of digital signatures other than our Ricardian Contracts. Check out OpenXades for their open source signatory architecture.
When asked, presenter Tarvi Martens from operator AS Sertifitseerimiskeskus (SK) claimed that the number of applications was in the thousands. How is this possible? By the further simple exigency of not having any applications on the card, and asking the rest of the country to supply the applications. In other words, Estonia issued a zero-application smart card, and banks can use the basic tools as well as your local public transport system.
Anybody who's worked on these platforms will get what I am saying - all the world spent the last decade talking about multi-application cards. This was a seller's dream, but to those with a little structural and markets knowledge this was never going to fly. But even us multi-blah-blah skeptics didn't make jump to hypersmartspace by realising that the only way to rollout massive numbers of applications is to go for zero-application smart cards.
A few lucky architectural picks written up in the inevitable whitepaper will not however make your rollout succeed, as we've learnt from the last 10 years of financial cryptography. Why else did this work for the Estonians, and why not for anyone else?
Gareth Crossman, presenter from Liberty, identified one huge factor: the Napoleonic Code countries have a legal and institutional basis that protects the privacy of the data. They've had this basis since the days of Napoleon, when that enlightened ruler conquered much of mainland Europe and imposed a new and consistant legal system.
Indeed, Tarvi Martens confirmed this: you can use your card to access your data and to track who else has accessed your data! Can we imagine any Anglo government suggesting that as a requirement?
Further, each of the countries that has had success (Sweden was also presented) in national smart card rollouts has a national registry of citizens. Already. These registries mean that the hard work of "enrollment" is already done, and the user education issues shrink to a change in form factor from paper to plastic and silicon.
Finally,it has to be said that Estonia is small. So small that things can be got done fairly easily.
These factors don't exist across the pond in the USA, nor across the puddle in the UK. Or indeed any of the Anglo world based on English Common Law. The right to call yourself John Smith today and Bill Jones tomorrow is long established in common law, and it derives from regular and pervasive inteference in basic rights by governments and others. Likewise, much as they might advertise to the contrary, there are no national databases in these countries that can guarantee to have one and only one record for every single citizen.
The lesson is clear; don't look across the fence, or the water, and think the grass is greener. In reality, the colour you are seeing is a completely different ecosystem.
Adam reports that Eric reports that the IETF has run its first meeting on opportunistic cryptography. Called "Better Than Nothing Security" the Internet protocol people are starting to get antsy about the number of attacks on unprotected sessions on the net.
And why aren't these sessions being protected by crypto? Because the original protocols called for a full-scale certificate authority signed key infrastructure. Nobody can be bothered with that, so they leave the links unprotected. Hence the notion that IPSec gives nothing because it isn't being utilised, and they may as well start accepting that crypto that is deployed is more useful than crypto that isn't deployed.
It is now some time past since we've had to argue the case. Crypto protocol people now seem to be comfortable that opportunistic cryptography - the glorified conceptual name for "wot SSH does" - is a valuable service.
There's still a little bit of loose naming to clear out. Adam points out that labelling opportunistic cryptography as "leaps of faith" is hardly helpful. Worse, it's just going to point more attention at the flaws in the certificate authority model.
For SSH and similar designs, we have one small step of faith at the beginning, In that if we don't check the certificate of the other node, *and* there is one of those vanishingly rare MITM attacks, then there exists a vulnerability. In contrast, we've pretty much established that certificate authority models call for two huge leaps of faith: firstly, that all CAs are the same, which isn't supported by any theory known to me, and secondly, that you can trust your CA because he is a trusted third party.
That last is now a highly questionable act of faith, in the light of Verisign's conflict of interest. Given that, the old label for self-signed certificates as "snake oil certs" is laughable, especially when phishing is considered. Self-signed certificates can make a huge difference to phishing, if the certificates were indexes into user-controlled information on the special sites. In contrast, certificate authority ones make no difference until we actually do something like adding branding to web browsers. Which then should we be calling snake oil?
http://www.financialcryptography.com/mt/archives/000206.html
http://www.ietf.org/ietf/04nov/btns.txt
http://www.rtfm.com/movabletype/archives/2004_11.html#001174
http://www.emergentchaos.com/archives/000583.html
In line with my last post about using payment systems to stupidly commit crimes, here's what's happening over in the hacker world. In brief, some thief is trying to sell some Cisco source code he has stolen, and decided to use e-gold to get the payout. Oops. Even though e-gold has a reputation for being a den of scammers, any given payment can be traced from woe to go. All you have to do is convince the Issuer to do that, and this case, e-gold has a widely known policy of accepting any court order for such work.
The sad thing about these sorts of crooks and crimes is that we have to wait until they've evolved by self destruction to find out the really interesting ways to crack a payment system.
E-gold Tracks Cisco Code Thief
November 5, 2004 By Michael Myser
The electronic currency site that the Source Code Club said it will use to accept payment for Cisco Systems Inc.'s firewall source code is confident it can track down the perpetrators.
Dr. Douglas Jackson, chairman of E-gold Ltd., which runs www.e-gold.com, said the company is already monitoring accounts it believes belong to the Source Code Club, and there has been no activity to date. ADVERTISEMENT
"We've got a pretty good shot at getting them in our system," said Jackson, adding that the company formally investigates 70 to 80 criminal activities a year and has been able to determine the true identity of users in every case.
On Monday, a member of the Source Code Club posted on a Usenet group that the group is selling the PIX 6.3.1 firewall firmware for $24,000, and buyers can purchase anonymously using e-mail, PGP keys and e-gold.com, which doesn't confirm identities of its users.
PointerClick here to read more about the sale of Cisco code.
"Bad guys think they can cover their tracks in our system, but they discover otherwise when it comes to an actual investigation," said Jackson.
The purpose of the e-gold system, which is based on 1.86 metric tons of gold worth the equivalent of roughly $25 million, is to guarantee immediate payment, avoid market fluctuations and defaults, and ease transactions across borders and currencies. There is no credit line, and payments can only be made if covered by the amount in the account. Like the Federal Reserve, there is a finite value in the system. There are currently 1.5 million accounts at e-gold.com, 175,000 of those Jackson considers "active."
eWEEK.com Special Report: Internet Security To have value, or e-gold, in an account, users must receive a payment in e-gold. Often, new account holders will pay cash to existing account holders in return for e-gold. Or, in the case of SCC, they will receive payment for a service.
The only way to cash out of the system is to pay another party for a service or cash trade, which Jackson said creates an increasingly traceable web of activity.
He did offer a caveat, however: "There is always the risk that they are clever enough to figure out an angle for offloading their e-gold in a way that leads to a dead end, but that tends to be much more difficult than most bad guys think."
This is all assuming the SCC actually receives a payment, or even has the source code in the first place.
PointerDavid Coursey says securing source code must be a priority. Read about it here.
It's the ultimate buyer beware-the code could be made up, tampered with or may not exist. And because the transaction through e-gold is instantaneous and guaranteed, there is no way for the buyer to back out.
Next Page: Just a publicity stunt?
Dave Hawkins, technical support engineer with Radware Inc. in Mahwah, N.J., believes SCC is merely executing a publicity stunt.
"If they had such real code, it's more likely they would have sold it in underground forums to legitimate hackers rather than broadcasting the sale on Usenet," he said. "Anyone who did have the actual code would probably keep it secret, examining it to build private exploits. By selling it, it could find its way into the public, and all those juicy vulnerabilities [would] vanish in the next version."
PointerFor insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzer's Weblog.
"There's really no way to tell if this is legitimate," said Russ Cooper, senior scientist with security firm TruSecure Corp. of Herndon, Va. Cooper, however, believes there may be a market for it nonetheless. By posting publicly, SCC is able to get the attention of criminal entities they otherwise might not reach.
"It's advertising from one extortion team to another extortion team," he said. "These DDOS [distributed denial of service] extortionists, who are trying to get betting sites no doubt would like to have more ways to do that."
PointerCheck out eWEEK.com's Security Center for the latest security news, reviews and analysis.
Here is an innovative payment system that the IRS (United States tax department) claimed (successfully) was employed to avoid tax.
"President of Construction Company Sentenced"On June 24, 2004, in Billings, Montana, Ron Omo, president of Big O Construction, Inc., was sentenced to 2 years probation and ordered to pay restitution of $21,224. In addition, Omo was fined $10,000 and the Big O Corporation was fined $40,000. Omo pleaded guilty on February 5, 2004, to charges of disclosing false information on IRS Form 1096, Annual Summary of Information Returns, by not including IRS Form 1099, Miscellaneous Income, evidencing income received by persons driving vehicles for the benefit of Omo and Big O Construction.
"Omo established a payment system for 36 truck drivers employed by Big O Construction, whereby the drivers submitted "driving slips" to bill for driving services and other miscellaneous work provided to the company. Omo and Big O Construction paid the drivers based upon the driving slips instead of time cards. Under this system, no benefits, unemployment insurance or other employment taxes were paid in connection with the driving slip payments. No year end summaries "Form 1099's" were issued to the 36 drivers with respect to the work accounted for by "driving slips." By not issuing year end summaries, Omo and Big O Construction assisted the drivers in their non-reporting of income when the drivers filed their individual tax returns. The practice of paying drivers through the use of drivers slips, failing to report the payments to the IRS, and the drivers failing to include the payments on their individual income tax returns, resulted in an aggregate federal income tax loss totaling $21,224."
This notion that independent payment systems are useful for avoiding tax has always dogged the small payment systems operators. It's a sort of "you're different so you must be evil" slander. In my experience it is pretty rare that a) any operator thinks in these terms and b) they have any significant clientele that use payment systems to avoid tax.
The reason for this is easy to explain: most payment systems out there provide quite clear trails to "follow the money." They have to do this; if they don't, they tend to lose money through user error, support failures, system bugs and theft. Payment systems have to first and foremost provide safe money.
Of course, that doesn't mean that a customer can't use the payment system as an adjunct to some tax avoiding scheme (or is it tax evasion? I can never remember which is which). Sure, that goes on in a few cases, but it's fundamentally nothing different to using the banks, or cash, or any other form. On the plus side it is often easier to open accounts in net payment systems, but on the minus side, the evidence is a lot clearer.
Then there are of course the payment systems that offer untraceable cash (sometimes called anonymous cash, but this is incorrect as all these systems have historically used identified accounts). Untraceable cash systems are unsustainable and dangerous places to leave your money; simply because when something goes wrong, you can't "follow the money" and that generally means that at some point, something will go wrong, and the system will collapse. Payment systems that can't keep their money safe don't operate for long.
This then means that these systems can only be used for washes - quick ins and outs. This is often hard to hide, and it puts further strain on the system. For example, I came across a regular wash through a payment system where every month the money would come in to the system, and the same day, often the same hour, money would go out again. Because the wires coming in and going out went through the same bank, this would be easy to spot, and you'd only have to ask...
Jeffrey Tucker has penned his observations of The Candy Economy, direct from the streets of Halloween. Some might be horrified at the conduct of Misean experiments on innocent children, but it sure beats the "Mice-like" experiments that are frequently conducted on adults by well meaning governments. After discussing all the evils and woes of such pagan festivals, he leaps into how the children discover prices and reinvent free trade:
"What children truly adore about Halloween is what takes place after the candy has been brought back to home base: the trading. Here is where the excitement begins.""No child can fully control what he or she is given, so it is up to that child to make exchanges with others in order to obtain what he or she really wants, and to do so in a strategic manner so that overall wealth is enhanced."
Read it all and laugh: http://www.mises.org/blog/archives/002672.asp