https://royalfork.github.io/btc-pgpBecause email encryption has been on the minds of many during the past year and a half, and GPG has recently released a “modern” version of their email encryption software supporting elliptic curve cryptography, I thought it would be fun to combine PGP encrypted email with the bitcoin blockchain.
A couple things which I think are cool about this idea:
- Public key exchange has been the achilles heel of many decentralized communications systems. Using the bitcoin blockchain as a decentralized public key server largely solves this problem (and it’s completely invisible to end users).
- Btc-PGP combines payment and messaging into a single communications channel. This could simplify marketplaces; a single email/transaction could order a product, specify a shipping address, include payment, and serve as it’s own receipt.
- Email could be sent with micropayments in an attempt to fight spam. Everyone who messages you must pay $.05. When replying, you send the micropayment back….or something like that (yes, I’m aware that fighting spam is hard).
If you’re interested in giving it a try, the following app will set you up with a testnet address and let you encrypt, decrypt, send, and receive PGP messages on the blockchain. Message me at: “mnpPDMjPFWhdzCHmfGKVbA9ohLJF2b2Q7N” and let me know what you think.
Technical points:
- All encryption is done in the browser with the bitcoinjs and openpgpjs libs.
- Blockchain data comes from the Chain.com API. Encrypted messages are hosted as github gists. I run my own testnet faucet and url shortening services. All of these things can easily be swapped out.
- secp254k1 is not an official PGP-ECC curve, so these messages will not work with GPG 2.1 (unless you build your own libgcrypt, and build from a special GPG 2.1 branch)
- The same testnet private key is responsible for both ecdsa (for signing bitcoin txns) and ecdh (for encryption/decryption). I understand that this is not best practice, but it doesn't break security (giant disclaimer: I am not a cryptographer, that's why this is on testnet).
- This system relies on address reuse, which is not ideal. Haven't really thought into whether this could work with BIP32....anyone know if that would be possible?
- OP_RETURN outputs are used for transport, which means sender/receiver pairs are public. It would be cool to use the shiny new "Dark Mail Transport Protocol" to get around this.
Any thoughts, questions, or criticisms will be gratefully received.
