Fwd: [gsc] Public Key Transaction Processor
R.A. Hettinga
rah at shipwright.com
Sat Jul 11 13:15:57 PDT 2009
Begin forwarded message:
> From: Patrick Chkoreff <patrick at rayservers.net>
> Date: July 11, 2009 12:19:22 PM GMT-04:00
> To: gold-silver-crypto at 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 at 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 at 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
More information about the cypherpunks-legacy
mailing list