R3 - the financial institution distributed ledger people - have published the first high level view of how we'll build the shared ledgers of the future:
Corda: An Introduction
Richard Gendal Brown, James Carlyle, Ian Grigg, Mike Hearn
A distributed ledger made up of mutually distrusting nodes would allow for a single global database that records the state of deals and obligations between institutions and people. This would eliminate much of the manual, time consuming effort currently required to keep disparate ledgers synchronised with each other. It would also allow for greater levels of code sharing than presently used in the financial industry, reducing the cost of financial services for everyone. We present Corda, a platform which is designed to achieve these goals. This paper provides a high level introduction intended for the general reader. A forthcoming technical white paper elaborates on the design and fundamental architectural decisions.
The paper of course speaks for itself, so there is little I can do to add. It's an introduction only, so members of the community looking for some meat will have to wait a bit.
Yet, let me share some background on the thinking that led to this design. When Richard gendal Brown was doing his initial musing on the nature of all things blockchain, he was aware that it was the coolest thing around; indeed blockchain was why R3 formed a consortium and why gendal jumped ship for future vibrant green pastures. And in the process, rounding up the usual suspects - James, Mike and myself - to muse and white board on what this future of blockchain would look like for banks.
Yet the history of coolest things in IT is dismal, frightening even. That led us on a search for what financial institutions really need or want. There are many things on that list, but two things stuck out like sore thumbs:
Right thumb - those managing the money of customers do so with privacy. It's no good if your bank decides to broadcast your wealth to the world; any leakage of any form of any value to anyone at all is a weakness that inevitably ends in theft. Privacy is security, and this was the origin of banking - the bank offered to keep your money in greater security and greater privacy than you could yourself. End of story.
And therefore, you can bang nails into your right thumb with your blockchain hammer as much as you like, but the fact remains that a public, shared blockchain is a non-starter - for banks. Before you say "but zerocash, but homomorphic encryption, but confidential transactions," let me just say, we all like science fiction as much as the next guy, but banks can't foister it on customers. Tell us about it in 5 years when it's actually proven to work.
Left thumb - Proof of Work is a killer. Last I heard, Bitcoin is consuming the power of Ireland for less than a million users. If we scale up 100 times, that gets us ... what? 100 million users and the power-equivalent of Europe?
Folks - get real. If the energy numbers mean nothing to you, try this for size: The USA and Russia are currently running a proxy war in Syria because some sheik wants to run a gas pipeline down to Europe. In short, wars get started over that amount of energy. Bitcoin, noble experiment that it was, will not be used by major institutions, if only because it's bad for business if the public think that the banks are the cause of more energy wars.
This is not necessary. The reason for PoW was that we cannot trust the sybil element of an open access system - necessary to ensure the fabled censorship resistance. But in the institutional market, they know how to trust each other. They've been doing that for 100s of years. Literally - with letters of credit, trade finance, introductions, short term loans and interconnects, relationships.
Institutions don't need proof of work. They do need proof of something else, sometimes fallaciously and naively known as identity. They can rely on their existing networks and systems to provide that, and, inefficient and systemically dangerous as the current 'identity' system is to the world of finance, it is probably less costly than a war. Identity of course is a more complicated story, one that is as yet little understood, and it's a story for a book worth of posts, so let's not get distracted.
Back to R3's Corda: Without proof of work, and without the public blockchain, we are really talking about a completely different animal to Bitcoin. And that's what Corda is - a redesign from the base requirements of the institutions. For what that animal looks like, read the paper, and look out for a forthcoming technical paper.
One of the things that has clearly outlined the dilemma for the academic community is that papers that are self-published or "informally published" to borrow a slur from the inclusion market are making some headway, at least if the Bitcoin paper is a guide to go by.
Here's a quick straw poll checking a year's worth of papers. In the narrow field of financial cryptography, I trawled through FC conference proceedings in 2009, WEIS 2009. For Cryptology in general I added Crypto 2009. I used google scholar to report direct citations, and checked what I'd found against Citeseer (I also added the number of citations for the top citer in rightmost column, as an additional check. You can mostly ignore that number.) I came across Wang et al's paper from 2005 on SHA1, and a few others from the early 2000s and added them for comparison - I'm unsure what other crypto papers are as big in the 2000s.
|Conf||paper||Google Scholar||Citeseer||top derivative citations|
|jMLR 2003||Latent dirichlet allocation||12788||2634||26202|
|NIPS 2004||MapReduce: simplified data processing on large clusters||15444||2023||14179|
|CACM 1981||Untraceable electronic mail, return addresses, and digital pseudonyms||4521||1397||3734|
|self||Security without identification: transaction systems to make Big Brother obsolete||1780||470||2217|
|Crypto 2005||Finding collisions in the full SHA-1||1504||196||886|
|SIGKDD 2009||The WEKA data mining software: an update||9726||704||3099|
|STOC 2009||Fully homomorphic encryption using ideal lattices||1923||324||770|
|self||Bitcoin: A peer-to-peer electronic cash system||804||57||202|
|Crypto09||Dual System Encryption: Realizing Fully Secure IBE and HIBE under Simple Assumptions||445||59||549|
|Crypto09||Fast Cryptographic Primitives and Circular-Secure Encryption Based on Hard Learning Problems||223||42||485|
|Crypto09||Distinguisher and Related-Key Attack on the Full AES-256||232||29||278|
|FC09||Secure multiparty computation goes live||191||25||172|
|WEIS 2009||The privacy jungle: On the market for data protection in social networks||186||18||221|
|FC09||Private intersection of certified sets||84||24||180|
|FC09||Passwords: If We’re So Smart, Why Are We Still Using Them?||89||16||322|
|WEIS 2009||Nobody Sells Gold for the Price of Silver: Dishonesty, Uncertainty and the Underground Economy||82||24||275|
|FC09||Optimised to Fail: Card Readers for Online Banking||80||24||226|
What can we conclude? Within the general infosec/security/crypto field in 2009, the Bitcoin paper is the second paper after Fully homomorphic encryption (which is probably not even in use?). If one includes all CS papers in 2009, then it's likely pushed down a 100 or so slots according to citeseer although I didn't run that test.
If we go back in time there are many more influential papers by citations, but there's a clear need for time. There may well be others I've missed, but so far we're looking at one of a very small handful of very significant papers at least in the cryptocurrency world.
It would be curious if we could measure the impact of self-publication on citations - but I don't see a way to do that as yet.
In a bit of an experiment, I'm trying out an article using google docs. The topic of the article is how we relate my Ricardian Contacts to Nick Szabo's Smart Contacts.
This has always been a tricky topic but it should be easy. And in the end it is: the two are more or less orthogonal and independent ways to help people enter into agreements to do stuff. Both - slightly incorrectly - claim to be the contract whereas the courts know who sets the real contract. They do!
It's a bit of an experiment because the google docs rendition of this paper is totally open. Anyone can edit it! Crazy -- maybe ISIS will dive in an and render it all Koranic or our heads off!
In contrast to security wisdom, I've seen this sort of open document editing a few times now, and the result has been entirely polite and consensual. So let's give it a go. Comments welcome, you just highlight the words, and bring up the menu.
New paper for circulation by Ken Griffith and myself:
Bitcoin Verification Latency
The Achilles Heel for Time Sensitive Transactions
Abstract.Bitcoin has a high latency for verifying transactions, by design. Averaging around 8 minutes, such high latency does not resonate with the needs of financial traders for speed, and it opens the door for time-based arbitrage weaknesses such as market timing attacks. Although perhaps tractable in some markets such as peer to peer payments, the Achilles heel of latency makes Bitcoin unsuitable for direct trading of financial assets, and ventures seeking to exploit the market for financial assets will need to overcome this burden.
As with the Gresham's paper, developments moved fast on this question, and there are now more ventures looking at the contracts and trading question. For clarification, I am the secondary author, Ken is lead.
The various and many anonymous authorities are moving against BitCoin, and they are taking the time-tested path: shutting down the exchange operators.
This is the modus operandi that was employed with earlier innovative money suppliers, and unfortunately it is a bit of a killer strategy. In short, someone complained, someone else then lent on the major money operators, who lent on the minor ones providing exchange facilities, who in turn then pulled their accounts with the exchangers.
Paxum Ceases Business With Bitcoin
Over the course of the last two weeks, Paxum has been in communication with our banking partners, Mastercard, and our auditors to evaluate the best interests of Paxum (and its clients) in relation to Bitcoin.
After much discussion and consideration it has been decided that, though Bitcoin's are not illegal, they are considered high risk.
Where, 'high risk' might mean that the people who we rely on to stay in business don't like it, which makes the exchange business extremely vulnerable. Or it might mean that the Bitcoin economy has fundamental problems.
Now, it turns out that honest people have good reason to be suspicious of Bitcoin, up to and including the extreme levels of rampant criminality. And, Philipp Güring and I wrote the paper to explain it:
Philipp Güring and Ian Grigg, Bitcoin & Gresham's Law - the economic inevitability of Collapse (PDF)
Abstract. The Bitcoin economy exhibits remarkable and predictable stability on the supply side based on the power costs of mining. However, that stability is challenged if cost-curve assumption is not solely expressed by the fair cost of power. As there is at least one major player, the botnets, that can operate at a power-cost-curve of zero, the result is a breach of Gresham's Law: stolen electricity will drive out honest mining. This has unfortunate effects for the stability of the Bitcoin economy, and the result is inevitable collapse.
Philipp started by modelling demand and supply for Bitcoin mining. My part was to add the economics rationale why such things cannot succeed.
It is probably a bit too late now, but we had hoped to get the paper into some relevant forum but events above have overtaken us. Hence, here it is in the style of FC++ which means we might do some tweaking, and present it somewhere in a future moment.
A quick glance at the calendar reveals that it has been a year since the last FC++. Too long, so amends must be made! Our experiment in peer-reviewed, pre-review continues. Advances in Financial Cryptography, Number Three is released as three blog posts to follow.
This issue introduces capabilities, software engineering and dash of economics, all with relevance to this year's emerging security crisis.
Mark Miller, Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control
Philipp Gühring, Concepts against Man-In-The-Browser Attacks
Ian Grigg, The Market for Silver Bullets
Our mission is to solicit comments, feedback, and criticism from peers in the financial cryptography community in order to polish these documents for wider publication. To that end there will be 3 blog entries following, each with the abstract of the paper concerned. You can comment directly on the blog, or at a pinch mail the author directly.
For those who wish to link to FC++ and pick up all the advances without the rest of the blog, use this URL: https://www.financialcryptography.com/mt/archives/cat_fc.html which will get you the category including all articles. Note that you can drop the https if you are annoyed at the CAcert popup!
Financial cryptographer Mark Miller has finished his PhD thesis, formally entitled Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control.
This is a milestone! The thrust of Dr Miller's work could be termed as "E: a language for financial cryptography applications." Another way of looking at it could be "Java without the bugs" but that is probably cutting it short.
If this stuff was in widespread usage, we would probably reduce our threat surface area by 2 orders of magnitude. You probably wouldn't need to read the other two papers at all, if.
When separately written programs are composed so that they may cooperate, they may instead destructively interfere in unanticipated ways. These hazards limit the scale and functionality of the software systems we can successfully compose. This dissertation presents a framework for enabling those interactions between components needed for the cooperation we intend, while minimizing the hazards of destructive interference.
Great progress on the composition problem has been made within the object paradigm, chiefly in the context of sequential, single-machine programming among benign components. We show how to extend this success to support robust composition of concurrent and potentially malicious components distributed over potentially malicious machines. We present E, a distributed, persistent, secure programming language, and CapDesk, a virus-safe desktop built in E, as embodiments of the techniques we explain.
Advisor: Jonathan S. Shapiro, Ph.D.
Readers: Scott Smith, Ph.D., Yair Amir, Ph.D.
Presented here as the lead article in FC++. Mark's generous licence:
Copyright © 2006, Mark Samuel Miller. All rights reserved.
Permission is hereby granted to make and distribute verbatim copies of this document without royalty or fee. Permission is granted to quote excerpts from this documented provided the original source is properly cited.
This emerging threat has sent a wave of fear through the banks. Different strategies have been formulated and discussed in depth, and just this month the first roll-outs have been seen in Germany and Austria. This information cries out for release as there are probably 10,000 other banks out there that would have to go through and do the work again.
Philipp Gühring has collected the current best understanding together in a position paper entitled "Concepts against Man-in-the-Browser Attacks."
Abstract. A new threat is emerging that attacks browsers by means of trojan horses. The new breed of new trojan horses can modify the transactions on-the-fly, as they are formed in in browsers, and still display the user's intended transaction to her. Structurally they are a man-in-the-middle attack between the the user and the security mechanisms of the browser. Distinct from Phishing attacks which rely upon similar but fraudulent websites, these new attacks cannot be detected by the user at all, as they are use real services, the user is correctly logged-in as normal, and there is no difference to be seen.
The WYSIWYG concept of the browser is successfully broken. No advanced authentication method (PIN, TAN, iTAN, Client certificates, Secure-ID, SmartCards, Class3 Readers, OTP, ...) can defend against these attacks, because the attacks are working on the transaction level, not on the authentication level. PKI and other security measures are simply bypassed, and are therefore rendered obsolete.
If you are not aware of these emerging threats, you need to be. You can either get it from sellers of private information or you can get it from open source information sharing circles like FC++ !
In this paper I dip into the esoteric theory of insufficient markets, as pioneered by Nobel Laureate Michael Spence, to discover why security is so difficult. The results are worse than expected - I label the market as one of silver bullets. Yes, there are things that can be done, but they aren't the things that people have been suggesting.
This paper is a bit tough - it is for the serious student of econ & security. Far from being the pragmatic "fix this now" demands of Philipp Gühring and the "rewrite it all" diagnosis of Mark Miller, it offers a framework of why we need this information out there in the public sphere.
What is security?
As an economic `good' security is now recognised as being one for which our knowledge is poor. As with safety goods, events of utility tend to be destructive, yet unlike safety goods, the performance of the good is very hard to test. The roles of participants are complicated by the inclusion of agressive attackers, and buyers and sellers that interchange.
We hypothesize that security is a good with insufficient information, and reject the assumption that security fits in the market for goods with asymmetric information. Security can be viewed as in a market where neither buyer nor seller has sufficient information to be able to make a rational buying decision. These characteristics lead to the arisal of a market in silver bullets as participants herd in search of best practices, a common set of goods that arises more to reduce the costs of externalities rather than achieve benefits in security itself.
Does it really show that the security market is one of silver bullets, and best practices are bad, not good? You be the judge! That's what we do in FC++, put you in the peer-review critic's seat.
It was widely recognised since David Chaum's designs first appeared that the new 'digital certificate' model of money was not aligned or symmetrical with accounting techniques such as double entry book keeping. Many people expected the two to compete and indeed many money systems avoided combining them; this is I believe one of the few efforts to integrate the two and show them as better in combination than apart.
The digitally signed receipt, an innovation from financial cryptography, presents a challenge to classical double entry bookkeeping. Rather than compete, the two melded together form a stronger system. Expanding the usage of accounting into the wider domain of digital cash gives 3 local entries for each of 3 roles, the result of which we call triple entry accounting.
This system creates bullet proof accounting systems for aggressive uses and users. It not only lowers costs by delivering reliable and supported accounting, it makes much stronger governance possible in a way that positively impacts on the future needs of corporate and public accounting.
Comments below as always!
Nick Szabo is one of the few people who can integrate contracts into financial cryptograpy. His work with smart contracts echoes around the net, and he last year he gave the keynote presentation at the Workshop on Electronic Contracts. In this paper he seeks to integrate scarcity and property constructs with the object oriented model of programming.
Scarce objects, a.k.a. conserved objects, provide a user and programmer friendly metaphor for distributed objects interacting across trust boundaries. (To simplify the language, I will use the present tense to describe architectures and hypothetical software). Scarce objects also give us the ability to translate user preferences into sophisticated contracts, via the market translator described below. These innovations will enable us for the first time to break through the mental transaction cost barrier to micropayments and a micromarket economy.
A scarce object is a software object (or one of its methods) which uses a finite and excludable resource -- be it disk space, network bandwidth, a costly information source such as a trade secret or a minimally delayed stock quotes, or a wide variety of other scarce resources used by online applications. Scarce objects constrain remote callers to invoke methods in ways that use only certain amounts of the resources and do not divulge the trade secrets. Furthermore, scarce object wrappers form the basis for an online economy of scarce objects that makes efficient use of the underlying scarce resources.
Scarce objects are also a new security model. No security model to date has been widely used for distributing objects across trust boundaries. This is due to their obscure consequences, their origins in single-TCB computing, or both. The security of scarce objects is much more readily understood, since it is based on duplicating in computational objects the essential security features of physical objects. This architecture is "affordable" in Donald Norman's sense, since human brains are designed to reason in much more sophisticated ways about physical objects than about computational objects. It is thus also "affordable" in terms of mental transaction costs, which are the main barrier to sophisticated small-scale commerce on the Net. Finally, it will solve for the first time denial of service attacks, at all layers above the primitive scarce object implementation.
Comments below please!
Petnames evolved out of hard-won experience in the Electric Communities project, and went on to become a staple within the capabilities school of rights engineering. But it wasn't until Bryce 'Zooko' Wilcox made his dramatic claims of naming that petnames really discovered their place in the financial cryptographer's armoury.
Petnames were previously undocumented in any formal sense and disseminated by word of mouth and tantalising references such as Mark Miller's Pet Names Markup Language. Marc Stiegler, visiting researcher at HP Labs, has now stepped up and collected the community knowledge into one introductory piece, "An Introduction to Petname Systems." He has done us a grand service and deserves our thanks for putting petnames onto an academically sound footing:
Zooko's Triangle argues that names cannot be global, secure, and memorable, all at the same time. Domain names are an example: they are global, and memorable, but as the rapid rise of phishing demonstrates, they are not secure.
Though no single name can have all three properties, the petname system does indeed embody all three properties. Human beings have been using petname systems since long before the advent of the computer. Informal experiments with Petname-like systems in computer-oriented contexts suggest that petnames are intuitive not only in the physical world but also in the virtual world. Proposals already exist for simple extensions to existing browsers that could alleviate (possibly dramatically) the problems with phishing. As phishers gain sophistication, it seems compelling to experiment with petname systems as part of the solution.
We seek comments below. Petnames is a very important concept in naming and if you design complicated financial cryptography systems it will be well worth your while to be at least familiar with the arguments within.
Our experiment in peer-reviewed, pre-review continues. Advances in Financial Cryptography, Number Two is here! This issue is strong on Software Engineering as both Nick and Mark discuss software constructs amenable to constructing Rights systems. Accounting also makes a rare appearance in a battle between crypto and double entry bookkeeping.
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting
Our mission is to solicit comments, feedback, and criticism from peers in the financial cryptography community in order to polish these documents for wider publication. To that end there will be 3 blog entries following, each with the abstract of the paper concerned. You can comment directly on the blog, or at a pinch mail the author directly.
#1 was a success, earning 12 comments that otherwise would not have been found. Thanks to all the critics out there and keep the pen sharpened.
I'm now on the hunt for articles for FC++ #3 so get working on those drafts, folks! The acceptance criteria is pretty open - if it is FC and it's got something valuable to say, let's try it out.
For those who wish to link to FC++ and pick up all the advances without the rest of the blog, use this URL: https://www.financialcryptography.com/mt/archives/cat_fc.html which will get you the category including all articles. Note that you can drop the https if you are annoyed at the cert popups!
Judging by the private comments I have received, Advances in Financial Cryptography (FC++) has worked well. I now have a potential list of 3 more papers ready for distro!
Question now is how to proceed. I'm open to comments on this; I see these options to publish:
It mostly depends on what works for readers, authors and reviewers, let me know (privately as desired). One short term factor is that there is a bit of a backlog of papers for review, so versatility might be needed.
Presumably the copyright is owned by the author, even when published there, but does the JIE take on the "first publication" title? That is, would either David or the editor of another (paper) journal consider this as prior publication? It was specifically to answer this that I couched our FC++ as a pre-review forum, with explicit encouragement to go on to the next stage, "real publication" whatever that may be.
Secondly, David talks about adding a rating system, and I wasn't able to see that, but it would be good to see how that went. My own view is that rating systems are tough; and I'm going to stick to encouraging people to go free form on comments. People here have shown themselves to do so, and they haven't held back through politeness. That's good, as healthy criticism is essential.
Having said all that, maybe there is a view towards a rating system in the future. Here's one thought: A comments currency. Hypothetically, someone making a comment could earn points for making comments, and a paper author could award some as well for value. Citations could earn more points.
Academics might point out that research should not be so crassly monetarised, to which I'd point to the current tendency to measure all academic work by citations and papers published. Maybe the benefit of this system is that it is such a filtered and inefficient money, as when one focuses in too closely on the citations count, this creates a sort of "winner's curse".
Oh, and news just in, JIBC has published its "Spring issue." My article "Phishing - what it is and how it will eventually be dealt with" is in there. Could be useful if you need a fairly compressed, managerial update on the subject.
More on the other articles later.
I'm proud to announce our "first issue" of Advances in Financial Cryptography! These three draft papers are presented, representing a wide range of potential additions to the literature:
Daniel Nagy, On Secure Knowledge-Based Authentication
Adam Shostack, Avoiding Liability: An Alternative Route to More Secure Products
Ian Grigg, Pareto-Secure
In each of the following three entries, I present the abstract for each. Please click on the link and read the paper - either all of them or just the ones that take your fancy. Your real benefit and contribution is the ability to post comments on that paper.
Forum guidelines are below, taken from an earlier post. Remember, FC++ is a forum to help budding authors make budding papers better. The more you can post your impressions, the more we can help to advance the field.
FC++ presents its first working paper by Daniel Nagy that discusses how better to combine password access with public key access. This potentially innovative crypto idea may solve a big Rights layer issue. Onwards:
"One-factor user authentication, where the user is required to prove the knowledge of a single secret in order to authenticate herself, is by far the cheapest method to confirm one's identity. Because of its simplicity and low costs, it is one of the most popular authentication methods on the internet. By now, it became quite natural to identify ourselves by typing in our user id and a password in order to gain access to remote resources or authorize various transactions.
However, knowledge-based authentication has a number of challenges and, in fact, it has become the primary target for on-line criminals. In this paper, I will present a novel approach to knowledge-based one-factor authentication that solves many problems, thwarting most common attacks against such systems, while retaining its simplicity and convenience. It is achieved by the means of identity-based public key cryptography: the public/private key pair is generated directly from the unique user id and a secret password. Both provable and zero-knowledge authentication are discussed.
In financial applications, it is essential that users can accurately estimate the value with which they are entrusting service providers. In particular, this value needs to be clrearly bounded from above; the damage from any malicious or erroneous action on the service provider's part should not exceed this limit. The proposed authentication method does not let the service provider to unilaterally compromise the user's security with respect to other systems — a feature certainly lacking from many authentication schemes currently in use.
The proposed method has broader applications than authentication. For example, it allows for a digital signature scheme that matches paper-based signatures more closely in that the signer does not need to own any unique key for a signature, just have access to a general-purpose signing application (a pen) that can be shared by any number of users and know a secret that she can remember."
As this is the first FC++ paper, I should quickly summarise what our intention is here. This paper is a working document, seeking peer review in preparation for wider publication and submission to a more formal forum. Comments are therefore desired and even sought after! Please read the paper, and put any thoughts into a comment in this blog. Feel free to distribute the link. Enjoy!
Advances in Financial Cryptography (FC++) presents an essay in draft by Adam Shostack on alternates to liability for makers of security software. Can we avoid liability for failed FC apps?
A healthy debate is raging over extending liability rules to software companies. Respected security experts and economists argue that it is an effective way to force companies to internalize externalities. After all, if a company can spend nothing on security, and produce a product that customers will buy, why should they spend on security? If customers can't distinguish between a secure and an insecure product, the company that produces an insecure product will get to market first, and have an advantage. This shifts the high cost of dealing with insecurities to customers, who are in a poor position to fix the products they have purchased. Thus, imposing liabilities on software producers will induce them all to take care in the creation of their software.
Responses to this argument include that it will dampen entrepreneurship, because a large companies will find it easier to influence, and then comply with the "industry standard" practices that limit their liability. At the same time, corporate executives are focused on trying to limit their liabilities, rather than shift them around (WSJ). This executive opposition, coupled with contract provisions now being imposed by large buyers may be enough to prevent general software liability over the next several years.
What is a customer who wants better software to do? Twenty years ago, there was no good way for a customer to judge the quality of a used car. The dealer knows more about it than the customer reasonably can. It's expensive to bring twenty used cars to your mechanic to get them checked out, and besides, he may see your lemon as his paycheque.
Studying this market earned Akerlof and Spence a Nobel prize: They talk about assymetric information, lemons markets, and signaling, which is a message that's cheap to send if you are a high quality provider, but expensive if you're not.
Today, we have a number of ways of signaling the quality of a used car, including dealer-backed warranties, certified-pre-owned programs, and Carfax, which is a background checking system for cars. Can we take useful lessons from this for security? This essay will first look at some objections to the idea of signaling for security, examine some possible signals, critique those signals, and then compare signals to liability as a means to achieve appropriate security for an organization.
This is our second FC++ presentation, and brings in an important nexus of economic thought to assist us with secure applications. Adam intends to present this essay informally at the rump session of the forthcoming Economics and Security Workshop. Comments by peers can only help! Feel free to distribute the link. Enjoy!
Editor's apology! The email notification to this entry failed consistently 4 times. A mystery.
To round off our first foray into peer-review, FC++ presents a paper my own observations on a term dear to our hearts, if not our heads. Can an economics framework explain what we mean by security?
What do people mean when they say something is secure?
Shamir's 1st law says absolute security does not exist, yet the popular press and the security buying process is inundated in secure product. For some of these products, there may be merit in the term, but for many it is more debatable. Such differences of meaning and applicability suggest low efficiency in the market for security, as well as a blackspot on the claim for security as a robust science.
One way to define 'secure' is to apply the economics theory and terminology of Pareto efficiency. This simple structure gives an easy way to categorise and choose among alternates, and identifies when an optimum has been reached. We suggest that this meaning may already be in wide spread usage, intuitively, among security practitioners and the popular press.
As always, comments welcome. For all FC++ discussions, we are interested in where you think these papers might be better published.
I'd like to develop the idea of a forum for peer-reviewing papers, introduced in a previous post. To recap, I suggested a sort of pre-publication review circle, which was basically derived from Adam's thoughts on non-academic peer-review.
I've found there are about half a dozen papers out there that would enjoy this process. That's a promising start! Each of these papers lacks the polishing gained by peers, and I know myself that I can get my own thoughts down fairly easily but it takes the critical attention of skeptics to move from muddle to polish.
I think there's a definate need. Here are some trial guidelines, but they are just some notes I jotted down. Comments definately demanded!