How to design online money secured without accounts or passwords.
This is a continuation of previous posts on money and encryption.
Let’s briefly review the kinds of money we’ve mentioned in the past and look at the weakest link in bypassing the security of each.
Bills, coins, and physical checks are hard to forge and even harder to get away with forging. We’ve spent centuries making them so. They’re not perfect, but they are pretty good.
Electronic checks strike me as being surprisingly easy to forge. If you’ve ever been asked to pay by e-check you’ll realize that all of the information you needed to know to do so was printed on every single physical check you’ve ever had. That said, I hear of very little e-check forgery. Perhaps this is because, in my experience at least, e-checks are only accepted for a few online transactions where the sender of the check is clearly identified, and hence the risk of apprehension is high.
The information you need to pay by plastic is also usually on the physical card, but even were it not, it is something that you give out every time you make a purchase. Often something you give to minimum-wage earners you’ve never seen before and will likely never see again who have limited job security and about whom you know nothing. I assume a priori that every credit card number out there is known by at least one person of evil intent. Fortunately, there is significant effort in tracking those who use stolen cards, so as long as you check your accounts to detect and report incorrect use, there is relatively low danger. But that safety is caused by enforcement, not security: plastic is almost inherently insecure.
Money brokers like PayPal are generally quite secure. PayPal has strong incentive not to betray your trust, and the way they facilitate interactions between merchant and purchaser does not involve stealable material in any form. However, PayPal is an account-based system; see the previous post for the plethora of weak links in password-protected account-based systems. Better forms of not-just-password authentication do exist (and PayPal has been early adopters of some of these) but accounts remain more hackable then the ideal.
BitCoin and other native-digital currencies are flawed by design—not in the digital security sense (though they might be flawed there too, I’ve never really checked) but in the economic value sense. Their weakest link the potential for complete and total currency collapse.
Last week as I was sitting in an airplane I realized how to make an all-digital, account-free technology for handling money. That thought was the impetus to write this series of posts. I have not thought it through a great deal, and I have not performed a very vigorous literature search to see if it has been proposed before, but I thought it worth sharing.
Since I’m not planning to implement it and have no interest in profiting from the idea, I release the remainder of this section of this post to the public domain. Unless, of course, someone else has patented it first, which I suppose could be possible; patents tend to be written using such obtuse and vague language that I find it quite difficult to discover if an idea has been patented or not.
Suppose a bank has a computer with a simple two-column table. One column has really big (hundreds of digits long) random numbers; the other column has the monetary balance associated with each random number. If you give the bank some money, it will create a new row in the table and tell you the random number. If you give the bank one of the random numbers and the correct balance for that number, it will give you the money and remove the row from the table. This is not unlike a normal bank if it had a new account number for each deposit instead of each client. For ease of subsequent conversation, and to distinguish them from bank accounts, let’s call the big random numbers “key”s.
Suppose the bank also makes available a simple web portal. The portal lets anyone send it a set of keys and a set of desired balances. For example, I might send “Divide keys {123…4, 937…3, 412…1} into two values, {$34.23, $103.15}”. If the keys all exist and their values total to the total of the requested values, the bank will remove all rows with the provided keys, add a new row for each requested balance, and return to the requester the new keys; for example, the requester might get back {443…4, 138…4}.
That is all the bank needs to do. Now, to perform a transaction:
The end result is that, besides some keys that are no longer in the bank, all the merchant learns is a key for the cost charged (a key the purchaser has never seen); all the purchaser learns is a key for the remaining money on balance (a key the merchant has never seen); and there are no accounts to be guessed or captured, no ability to use social engineering to get the bank to give away someone else’s money because the bank doesn’t know whose money is whose, etc. As long as the random numbers are large enough and created via unguessable (non-replicable non-mathematical) processes, there is no room for fraud Suppose ten billion people each have a hundred thousand keys. That puts only 1015 keys in the bank’s table. If the keys are 10300 digits long (common for encryption keys today) then the chance of guessing one is 10−285 per guess. At 1 billion guesses per nanosecond for 1 billion years there’s less than a 1 in 10250 chance of guessing one. And, since there is no pattern in the keys, there is no way to do better than random guessing. . Two kinds of trust need to exist: trust that the bank will honor its transactions (a kind of trust already built in to every bank transaction anyway) and trust that the bank’s database cannot be read by anyone with bad intentions.
Since public-key encryption is a link in any online transaction, weakening our banking system to that level of security does not weaken its weakest link. That observation allows a refinement of the account-free model that can make it more auditable and thus reduce the need to trust the bank.
Have the key of each row be a public key of a public-private key pair. The private key pairs are stored by the clients of the bank. Requests from the client to the bank now consist of {(public, private Sending private keys like this is not the usual use of public-key cryptography. We’re really only using the key pairs as hard-to-guess pairs where the bank needn’t know both pairs to verify the pairing. A simple adjustment would use a challenge/response approach to have the private key never be sent; that adjustment would also make row balances modifiable without creating new keys. ), (public, private) …} for the rows to empty and {(amount, public), (amount, public), …} for the rows to create. Only if the private keys match the public keys is the transaction allowed to proceed.
This system is not quite as unguessable as the previous one; there are patterns to key pairs that might someday be used to figure out what the keys are, and in any case they are much more guessable than purely random numbers of the same size. But it does mean that the bank can now make public the (key, amount) pairs on record so that anyone can verify that all transactions are above-board and that the money they have not spent is still in the bank. It also lets you see if someone has money without them giving it to you: they can encrypt something with their private keys and if you can decrypt them with the public keys on file then you know they have the ability to retrieve the money. Thus, they can “show their cash” without actually spending it.
But more importantly, storing one key from a key pair makes read-access to the banks computers less likely to result in theft. The banks needn’t store any private information at all, so read-access to their database doesn’t reveal anything useful.
Whether it is easier to block write-access than read-access is another matter. Clearly, if someone can write to the database arbitrarily then there is a large potential for mischief. But that is true of every digital money system I can imagine.
Cash is convenient because no one can steal it without your knowledge. But it is inconvenient because once it is stolen, it is gone. Lose your wallet and all of the cash it contains is gone.
Account-based systems do not generally have either of these properties. Someone can convince the system they are you and take money without your knowledge; but if you lose your credit card you can get a new one and (in most cases, if you are quick enough in reporting the theft) all your money is there, ready to be used. It is the same account-based weakness that lets it vanish that is the strength that lets it be recovered when lost.
The approach I outlined in the previous section removes accounts, and thus removes both the strength and the weakness that accounts provide. I don’t lose things very often so I think this sounds good. Others might disagree.
As a parting thought, account-free money needn’t remain digital. Print out a QR code of a key and you’ve got it on paper until you chose to spend it. But unlike bills today, those pieces of paper are single-use: you can back up your account-free digital money to paper, but it’s just a backup, and the moment someone else sees it it might lose all its value.
Looking for comments…