Fwd: [gsc] Public Key Transaction Processor

Begin forwarded message:

From: Patrick Chkoreff Date: July 11, 2009 12:19:22 PM GMT-04:00 To: gold-silver-crypto@rayservers.com Subject: Re: [gsc] Public Key Transaction Processor

Andrew McMeikan wrote, On 07/11/2009 10:44 AM:

...

About seven years ago, I started coding on a program for digital payments using pgp keys as accounts. ...

I hear ya Andrew. A long time ago I messed with a system for doing transactions via EMAIL, using PGP-signed messages.

I even set up an auto-responder with an address like "title@server.com", where "title" represented a "Title Server".

I was able to email it a signed message saying in effect:

Transfer 40 units from key A to key B. -- signed, key A

I'd email that to title@server.com. I had some Perl code which received that message automatically, verified the signature with key A, and returned a response signed with key T, where T represented the Title Server itself.

Of course, to prevent replay attacks, you need to include a nonce (one-time random number) in the message to make it unique. And then the Title Server needs to keep a database of those nonces to make sure a new message is not a replay. And then the question arises, when can you delete anything from that database, if ever.

Trubanc addresses that problem by having users effectively "sign off" on balances at every stage, enabling old history to be deleted.

I also played with a split/merge scheme, which is what eCache uses. But again, when can you ever delete a spent ID from the database, if ever?

The larger question is: even if the Title Server does all that, you end up with a fundamentally account-based system, and do we really want that?

One answer to that is to use *new key pairs* for different transactions. But the Title Server could still link those keys to IP addresses if an aggressor forced a programmer to include it in the code.

Even with eCache, an aggressor could force a programmer to include code that links the cash ID with an IP address and keeps a log of it.

eCache gets around that problem by *insisting* that you access their server through Tor. That way there's no feasible way for the eCache server to track a user's "real" IP address.

eCache also provides a "mixer" function to help obscure the trail.

Speaking of mixers, an email-based Title Server could rely on Mixmaster remailer technology to obscure real IPs. But as long as transfers are specified as FROM one key TO another key, there is still a danger if a particular key is ever linked to a human individual somehow, even if not by IP address.

Loom does not overcome this problem in any ultimate sense. An aggressor could force a programmer to insert logging code, which would associate Loom locations with IP addresses.

My thought was, to hell with it, if a user wants more anonymity, let him use an ANONYMOUS CHANNEL, such as Tor.

That's like the SSL mentality: if the user wants to communicate with a server securely, then the user should use a SECURE CHANNEL, i.e. SSL. That way the server itself doesn't have to do any cryptography, since the SSL layer handles that automatically.

Similarly, the TOR layer should provide an ANONYMOUS CHANNEL -- ideally. In practice, it would probably never be as anonymous as BLINDED SIGNATURES, but it's a start.

Even with Loom over Tor, an aggressor could still force a programmer to insert logging code. In that case the logs would associate locations with fairly meaningless IP addresses, so you might think privacy is preserved. However, if *somehow* a location was ever associated with a human individual (not by IP but by some other means), then a pattern of spends would begin to emerge to the aggressor's eyes.

If you wanted to play with a signature-based system which does NOT re-use keys, you might try something like Dan Bernstein's implementation of Elliptic Curve Cryptography, specifically a thing called "Curve25519":

http://cr.yp.to/ecdh.html

That uses very compact 256-bit numbers for both private and public keys, unlike the giant keys used in RSA.

Now that I'm on that topic, I'm thinking of incorporating that technology into Loom for the purpose of key exchange (i.e. conveying a secret location securely).

The nice thing about Curve25519 is that every user can have a 256-bit private key and a 256-bit public key. If two users Alice and Bob wish to exchange information securely, they can easily compute a shared secret location using only their own private key and the OTHER user's public key. (That's Diffie-Hellman key exchange.)

I have done a little research into blinded signatures, which could implement truly unlinkable payments, and it would be nice to use Curve25519 for that. However, the literature on the use of elliptic curve cryptography for blinded signatures is a bit scarce, and the papers which exist go very deep into some math which I am *capable* of understanding and implementing, should I care to spend an enormous number of hours of my life trying it.

I have not yet found any nice libraries for blinded signatures which I can simply *use* in my code. I'm really surprised that GnuPG has never included any blinded signature functions in their program. They have all the necessary discrete-log and strong-prime field code in their codebase, but as far as I know they've never implemented blinding functions.

So to summarize, yes I think you can implement a PGP-email based system, but it would fundamentally be account-based unless you re-used keys at every stage, which would be difficult for users.

You realize however that for VERY LARGE chunks of value, like let's say a whole 400 oz gold brick, one can use PGP-signatures manually to transfer "ownership".

The Title Server could simply sign a message saying in effect:

The gold bar belongs to key A. -- signed, T

A would then send a message to T, saying:

Please give the gold bar to key B. -- signed, A

Then the Title Server would say:

The gold bar belongs to key B. -- signed, T

Of course, the Title server would need to keep a record of all these messages so that it could justify the very latest owner. And the messages would have to be linked in a chain probably using a nonce, to avoid re-ordering them to justify a different owner. Then there's the problem of what happens if the Title server "forgets" a later part of the chain somehow, concluding that A is still the owner. But the new owner B would still have a copy of his signed message saying that he owns the bar. A lot of details to consider here, but in a manual system it might be workable, and for large asset values it could be cost- effective.

END stream-of-consciousness-with-no-proofreading

-- Patrick