Improving the trustworthyness of PGP keys with Bitcoin

[jdillon]

This sig was very clever:

AKA Peter Todd
1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
PGP: 37EC 7D7B 0A21 7CDB 4B4E  007E 7FAB 1142 67E4 FA04

It timestamps a PGP key fingerprint in the blockchain with a transaction an address generated directly from that fingerprint. (Note the hex URL) Thus even without the web of trust I can be pretty sure a year from now that I am looking at the correct key rather than an imposter.

What would it take to do this on a widespread scale? The PGP strong-set is a bit under fifty thousand keys right now. If transactions are cheap, perhaps a penny each, that would be just five hundred dollars and would greatly strengthen all those keys for the future. All the keys on the key servers is probably just a few million.

If anyone wants to make the strong set secure I will pay the transaction fees and a tip for your time. Proposals?

[1714129764]

1714129764

[1714129764]

1714129764

[1714129764]

1714129764

[Peter Todd]

Damn... I mean, from what little you have written on the forum and email list, I'm pretty sure you know this is a terrible idea.

You're trying to prove my point about how demand for blockchain space is unlimited if the price is low aren't you?

[jdillon]

Why not kill two birds with one stone?

[Peter Todd]

Why not kill two birds with one stone?

Well, you're not going to make friends, but yeah, there may be value in demonstrating yet another attack...

[jdillon]

Thank you to the anonymous individual who stepped up to make this happen. I hope the 1.5BTC was worth your time.

If you are part of the PGP strong set or your PGP key is on bitcoin-otc you now have a timestamp. Take your PGP fingerprint and convert that into a Bitcoin address and you'll find a 1 satoshi payment to it. For instance Peter's key is 37EC 7D7B 0A21 7CDB 4B4E  007E 7FAB 1142 67E4 FA04 which gives: https://blockchain.info/address/37ec7d7b0a217cdb4b4e007e7fab114267e4fa04

See also my response to Gavin's pull-request banning transactions less than 50uBTC: https://github.com/bitcoin/bitcoin/pull/2577#issuecomment-17138223

[dooglus]

Thus even without the web of trust I can be pretty sure a year from now that I am looking at the correct key rather than an imposter.

I don't understand.

What's to stop an impostor creating a key for that address and also posting it to the blockchain?

In a year's time you won't be able to tell the difference will you?  All the timestamp will tell you is that the key was made long ago.  It won't tell you who made it.

[jdillon]

I don't understand.

What's to stop an impostor creating a key for that address and also posting it to the blockchain?

In a year's time you won't be able to tell the difference will you?  All the timestamp will tell you is that the key was made long ago.  It won't tell you who made it.

Create the timestamp for your key at the same time you create it. Really when you decide your UID (your email address and name) needs a PGP key.

Any imposter won't be able to create a key with the same UID but with an even earlier timestamp. Essentially we are relying on the fact that you are not a target yet for an attacker.

Obviously there are caveats, but that is true of the web-of-trust too. The point is both measures go hand in hand and they both raise the barrier for any fraudster, just like the PGP keyring "verified email" thing raises the bar over not having it.

Audit measures don't need to be unbreakable to add security.

[Peter Todd]

This sig was very clever:

It's not as clever as you'd think.

I only timestamped the primary pubkey and nothing else. Really you also need to timestamp the User ID packets too, or an attacker can simply take an existing, timestamped, pubkey and create backdated UID packets and sign them. I think your PGP strong set timestamping project wasn't as useful as you thought it was. Or, to be exact, it only really benefits the people who were timestamped then, while future PGP fingerprint timestamps can be replaced by anyone in possession of a keypair you timestamped first. Not exactly a user experience conducive to easily and correctly evaluating security really.

You may find my recent post 'Timestamping' on the OpenPGP mailing list to be interesting.

EDIT: I point out though you did effectively demonstrate how Bitcoin with an unlimited blocksize is always threatened by foolish individuals expecting a negative return on their efforts... usually though that's demonstrated with gambling losses.

[Stardust]

A use for this is using firstbits. Generate a PGP key, until the firstbits are something memorable, then send a small transaction to the address. When give to someone the fingerprint over the phone, just give them the firstbits which is less prone to error.

Would be nice if we could find an alternative to the web of trust. That would also solve the problem with CAs in SSL.

[jdillon]

retep: Clever. Well at least I demonstrated one thing successfully.

Any idea what a proper implementation would look like? Could I just take the user ID packets hash them and timestamp those hashes?


stardust: Good idea. In fact you can kind of replace DNS with timestamping in general provided there is a window of time as the name expires where only the original person to register the name can grab it. Just constrain exactly how the name gets into the blockchain so you can verify that it does not yet exist before you register it.

That could be something as simple as including an additional payment to some specific address to mark your transaction as participating in the system, and at the same time make it easy to check if someone else has registered the name before by scanning the blockchain.

This would work really well with the upcoming UTXO proofs thing so you could prove to someone the name is actually registered right now, and yes, you are the owner. All the functionality of namecoin, but with the security of Bitcoin and without bolting on some silly early adopters get rich currency.

Of course the developers will try to block this system, so part of it should derive the "marker" address's secret key from the name being registered in a well defined way, thus making that address totally valid. The transaction would simply also carry other digests of data that was pre-commited, with potentially a P2P system for actually distributing that data, or just use it, like you say, as a name->pubkey certificate authority.

I really like this!

[jdillon]

OK, so here's the problem:

You want to associate an email with a PGP fingerprint right? So what you do is you take the email address, turn it into a Bitcoin address, and make a dust payment to that address. The email->Bitcoin marker scriptPubKey should be:

HASH160 Hash(email | magic) EQUALVERIFY

That say if gmaxwell's P2SH^2 thing is implemented it still looks like a valid address. It's now unspendable, so clients can easily find it in the UTXO set, and you can check if someone else has registered your address first by checking for existence in the UTXO set.

So that registers the name. Now to securely link that name to a PGP key, create a message consisting of simply the fingerprint, optionally sign it, and then create a multisig output:

1 Hash(message) <user-controlled pubkey> 2 CHECKMULTISIG

The pubkey is just there to give an easy way to show that the fingerprint has been changed to clients relying on proofs of the UTXO set contents in the future by spending that magic output.

The rules then are that the first registration *can* be unsigned, and latter ones *can not* be. (subject to say a 1 year expiration)

When the system is setup, someone the creator should secretely select the magic number mentioned above, timestamp as many PGP keys and user IDs from the keyservers as they can, then reveal the nonce publicly. As for those pubkeys, they can create individual ones for each key timestamped, encrypt the secret keys to the fingerprints being put into this CA, and make that data public so the true owners can spend those outputs and reassign them to their own pubkeys. Maybe even add that encrypted message to the insertion transactions as data to make it easier to retrieve.