Bitcoin Forum

Hi all,

I've written this python library that encrypts messages for a particular Bitcoin public key from a particular public key.  The message content is provably from the sender's Bitcoin address.  It is also hidden as ciphertext en route.  Only the recipient Bitcoin address can decrypt the contents.

Here's how it works.

a secret shared key between sender and receiver is created in the following way:

  - the sender scrapes the Blockchain (or some other source) for the recipient's public key.  Any transaction signed with pay_to_pubkey hash reveals the address's public key.  I wrote a small utility that scrapes this key, if available from transaction scripts, using the Blockchain.info API (although any other source would suffice).

 - Using the recipient's public key, the sender multiplies that point on the elliptic curve by his private key (ie the integer it represents).  A new point is created.

 - The new created point's coordinates map to a 32 byte string that is the shared secret key.

 - Meanwhile the sender broadcasts his public key as part of the encrypted message.  The recipient uses his private key to mulitply by the public point of the sender.  He should arrive at the same point calculated by the sender.  This maps again to the shared secret key.

Then I use AES-CBC to symmetrically encrypt the message contents using the shared secret key.

Finally, a timestamp is included in the encrypted message.  Received messages are only valid within X seconds of their creation by the sender.  This is a simple method to limit reply attacks to a brief window. 

This was my first foray into crypto, so I'd appreciate feedback and corrections.  Don't use this library as a finished product, as it has not been reviewed.  There could well be glaring errors I've missed.  I'm not a professional cryptographer so... take it with a grain of salt.

It's not safe to do this, you'd better use EC IES. First of all, there is no reason to use your private key. Secondly, AES CBC is not authenticated encryption and subject to chosen ciphertext attacks.

I think there is a need for this kind of encryption.  It also adds a layer of authentication, assuming that you somehow know an address is associated with an individual.   

Why can't you use ECC instead of AES?  Keypairs are already held by participants, shouldn't we be able to leverage this? 

Never roll your own crypto no matter how convenient.

Wait a minute, I support fully what OP is doing here.  He seems to be taking an opportunity to dig into the technology and learn about it.  Rolling your own __ is the best way to learn about __, imo.  Of course, if you're new, you need to be careful, but that's what OP seems to be doing. 

I wish I was savvy enough to comment on the particulars of this method/library, but alas...

For learning, yes, but it's easy to introduce a bug into crypto take a look at what happened to blockchain.info. So you shouldn't use stuff you wrote yourself for important purposes unless it's been analyzed and tested by millions of people.

I think the OP pretty specifically warns about just that---that this is an experimental, untested library that shouldn't be used for high-stakes purposes.

You can already do this with BitMessage I believe -- it uses secp256k1 for signing and symmetric cipher key exchange.

You just use ElGamal with elliptic curves. Classic ElGamal has been used by GPG for decades now.