Is it possible to create a message readable only to the owner of an address?

[namecoin]

Is it possible to encrypt a message so that only a certain address owner can read it? 

I guess there are two parts of the questions. 

1. I may not know the public key from the address because address is hash of public key.

From my understanding, the public key wouldn't be revealed until they have made a transaction. 

If I do not have the public key of the recipient, I guess I cannot do anything about it.

2. Let's say I do have the public key of the recipient address.  Could I then encrypt the message with the public key such that only the private key owner can read it?

Assuming that the address owner has revealed the public key in order to make a transaction, then we can find the public key from blockchain.  With this assumption, then we should be able to do this?

 

[gatra]

Yes, I believe it works as you describe it.

However, I don't know if there are tools to do it easily... probably not

[amaclin]

ECDSA is used for signing and verifying messages. Not for encrypting them.
So, the answer is "not".
You should use another crypto algorithms

[gatra]

ECDSA is used for signing and verifying messages. Not for encrypting them.
So, the answer is "not".
You should use another crypto algorithms

sure, ECDSA is for signing and not for encription, but the same keys used for ECDSA could be used for encryption, and it would work like what the OP needs...
so, while he must use an algorithm other than ECDSA, the answer would be yes.

[kingscrown]

or encrypt it and give key just to he owner so only he can decipher it

[etotheipi]

ECDSA is used for signing and verifying messages. Not for encrypting them.
So, the answer is "not".
You should use another crypto algorithms

sure, ECDSA is for signing and not for encription, but the same keys used for ECDSA could be used for encryption, and it would work like what the OP needs...
so, while he must use an algorithm other than ECDSA, the answer would be yes.

The private and public keys under ECDSA would not be related under another crypto scheme.  If you reinterpret your ECDSA private key as a private key of a different scheme, you'll surely get an unrelated public key.  It's not meaningful.

What you really want is ECIES (Elliptic Curve IES)

[DannyHamilton]

There are no new questions on bitcointalk (ok, perhaps a few, but not many).

This has been asked (and answered) in the past:

No.  Bitcoin uses ECDSA which is a digital signature algorithm not an encryption algorithm.  You could use another algorithm which supports encryption however Bitcoin address is not a Public Key it is a hash of the public key.   If you need to use a third party algorithm, third party software, and exchange keys directly well you might as well use something that was designed for this purpose like PGP.

There are encryption systems which can use ECC keys.  

ECIES is one system:
https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

However a couple things to keep in mind.   I don't know of any widely deployed open source software which uses it so you will be reinventing the wheel.  Could you develop such software, extensively test it, and then ensure your recipient also has said software (doesn't do much good if the recipient isn't using it) so that you can encrypt a message using a PUBLIC KEY you obtain (not address which is a public key hash) so the recipient can decrypt it by exporting a private key from his wallet into some software he is unfamiliar with?  Probably.

It wouldn't work any better than other widely deployed systems like PGP and unless you are very good you run the risk of compromise which affects both systems.  I would by default be suspect of any software where I have to export one or more private keys from my wallet (that control MONEYZ) to a third party software in order to  decrypt a message.  Even if legit it certainly doesn't sound smart or reasonable.

[gatra]

The private and public keys under ECDSA would not be related under another crypto scheme.  If you reinterpret your ECDSA private key as a private key of a different scheme, you'll surely get an unrelated public key.  It's not meaningful.

What you really want is ECIES (Elliptic Curve IES)

But aren't ECIES keys practically the same as ECDSA keys? isn't it just points on a curve?
So reinterpreting ECDSA keys as keys of EC encryption would work.

There are no new questions on bitcointalk (ok, perhaps a few, but not many).

This has been asked (and answered) in the past:

No.  Bitcoin uses ECDSA which is a digital signature algorithm not an encryption algorithm.  You could use another algorithm which supports encryption however Bitcoin address is not a Public Key it is a hash of the public key.   If you need to use a third party algorithm, third party software, and exchange keys directly well you might as well use something that was designed for this purpose like PGP.

There are encryption systems which can use ECC keys. 

ECIES is one system:
https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

However a couple things to keep in mind.   I don't know of any widely deployed open source software which uses it so you will be reinventing the wheel.  Could you develop such software, extensively test it, and then ensure your recipient also has said software (doesn't do much good if the recipient isn't using it) so that you can encrypt a message using a PUBLIC KEY you obtain (not address which is a public key hash) so the recipient can decrypt it by exporting a private key from his wallet into some software he is unfamiliar with?  Probably.

It wouldn't work any better than other widely deployed systems like PGP and unless you are very good you run the risk of compromise which affects both systems.  I would by default be suspect of any software where I have to export one or more private keys from my wallet (that control MONEYZ) to a third party software in order to  decrypt a message.  Even if legit it certainly doesn't sound smart or reasonable.

ok, I agree I wouldn't just put my private key in any software, but if I'm really curious about the message I'd transfer the funds to another address and then proceed to decrypt...

Adding it as a feature in the bitcoin client would be cool.

[DannyHamilton]

ok, I agree I wouldn't just put my private key in any software, but if I'm really curious about the message I'd transfer the funds to another address and then proceed to decrypt...

Adding it as a feature in the bitcoin client would be cool.

First you'd have to extract your public key from the client.

Then you'd have to securely get this public key somehow to the person that wants to send you a message (which reduces the security of your bitcoins a bit since they are no longer protected by the SHA256 and RIPEMD160 algorithms used to generate the bitcoin address).

Next the person that wants to send you the message would need to import that public key into some software (I think you're suggesting they import it into the Bitcoin Core client?)

After that they'd need to create the message and encrypt it.

They would send you the encrypted message which you would need to import into your Bitcoin Core client so that you could then decrypt it.

How and why is this better than using a well tested, well established, and well known system such as PGP?

[gatra]

How and why is this better than using a well tested, well established, and well known system such as PGP?

you may have a point there
I was just thinking that it may be cool to have and easy way (like, integrated to the qt-wallet) to securely send a message while being sure that the only recipient is the one who made a specific tx on the blockchain. That message could be used for exchanging pgp keys and we'd use pgp from there on...

[DannyHamilton]

How and why is this better than using a well tested, well established, and well known system such as PGP?

you may have a point there
I was just thinking that it may be cool to have and easy way (like, integrated to the qt-wallet) to securely send a message while being sure that the only recipient is the one who made a specific tx on the blockchain. That message could be used for exchanging pgp keys and we'd use pgp from there on...

Except that you'd have to get your Bitcoin public key to them in the first place.  You can't compute a public key from a Bitcoin address.

[gatra]

How and why is this better than using a well tested, well established, and well known system such as PGP?

you may have a point there
I was just thinking that it may be cool to have and easy way (like, integrated to the qt-wallet) to securely send a message while being sure that the only recipient is the one who made a specific tx on the blockchain. That message could be used for exchanging pgp keys and we'd use pgp from there on...

Except that you'd have to get your Bitcoin public key to them in the first place.  You can't compute a public key from a Bitcoin address.

Agreed. Doesn't look very useful, but for example if you have a public donation address you could send a private message to an anonymous donator (he revealed his public key while making the tx). If you include a pgp pubic key in your message he can answer you back.

[edmundedgar]

Here are some example implementations for encrypting with bitcoin public keys. (Not addresses, you'll need the public key.) No idea how much you can rely on these, I'd be interested to hear opinions.

ECIES:
node.js: https://bitcointalk.org/index.php?topic=627927.0
Python: https://github.com/planetbeing/bitcoin-encrypt

Not sure what this is:
https://github.com/jackjack-jj/jeeq (Python)
From the description of it here it seems to be original, which is cool but sounds like a good reason to prefer one of the other ones...
https://bitcointalk.org/index.php?topic=196378.5

[Abdussamad]

Electrum tried to implement message encryption/decryption in their software. gmaxwell found a bug in it so the feature was disabled. The next version, which is currently under development on their github repo, seems to have that feature enabled so maybe they've figured out a way to do it safely.

[Dabs]

Sign a message using your bitcoin client; the message is your PGP/GPG public key. Have the other guy do the same.

Then use PGP/GPG.

[BurtW]

I would think the message protocol would be pretty simple.

Assumptions:

You have the Bitcoin address and you know the Bitcoin address is controlled by the person you wish to send the message to.

The person to receive the message publishes their public key in the block chain and/or sends you a standard signed message to give you their public key.

Now you have the public key so you:

Create a random AES bulk encryption key (BEK).
Combine this one time use BEK with a known header.
Encrypt this combination using the public key.
This becomes the message header.

Encrypt the message with the random AES BEK.

Send the message header containing the encrypted BEK.
Send the encrypted message.

The receiver simply extracts the BEK from the message header with their private key and then decrypts the message with the one time use BEK.

Any holes in this?  

[luv2drnkbr]

This is basically what a stealth address is.

EC math has the property that pubkey1 * privkey2 = pubkey3, and privkey1 * pubkey2 = pubkey3.

Note that one of you always has to use a private key in order to get pubkey3.

So you can generate the shared secret pubkey3, use any kind of encryption you want, with pubkey3 as the password, and send that to them along with your own pubkey, and then they will use their private key and your public key to find the shared secret which is the password to the encrypted data.

[amaclin]

So you can generate the shared secret pubkey3

I think that OP wants to send message to a holder of arbitrary address without any previous communications with him.
Just broadcast some data (with special web-site or service?) which will be garbage for all of us, but a message for owner of bitcoin address.

[Peter R]

Greg told me that this method is insecure, but I still don't understand why.  Like luv2drnkbr implied above, if you know the pubkey of the address whose owner you wish to message, why can't you use the Diffie-Hellman technique to derive a symmetric key (shared secret) with which you encrypt the message?:

----------------
If the public key for the bitcoin address you want to send an encrypted message is known, then you can.  As far as I know, there are no tools that allow you to easily do this now, but they could be built.  

The encryption technique is based around the elliptic curve Diffie-Hellman protocol.  Assume Alice wants to send an encrypted message to the owner of bitcoin address B, and assume that Alice knows the pubkey for B.  

   Qa = Alice's public key
   da = Alice's private key
   Qb = public key of bitcoin address B
   db = private key of bitcoin address B

Since (da, Qa) and (db, Qb) are EC key pairs, we know that:

   Qa = da * G       and      Qb = db * G

where G is the elliptic curve base point. But look what happens when we multiply Alice's private key with the bitcoin address B's public key:

    S = da * Qb
       = da * (db * G)

It's almost the same thing as what we get when we multipy B's private key with Alice's public key:

   S' = db * Qa
      = db * (da * G)

Because points on an elliptic curve form a group, multiplication is commutative and associative (like normal multiplication).  This means that S = S':

   S = da * (db * G) = da * db * G = db * da * G = db * (da * G) = S'

I labelled this term "S" because this is a shared secret that the owner of bitcoin address B will soon know…

OK, so back to our encryption technique.  Alice hashes S to get a symmetric key:

    symmetric key = sha256(S)

and then encrypts her message using the symmetric key.

She then posts the encrypted message somewhere public, and then sends a bitcoin transaction to address B with an OP_RETURN output that specifies (using a to-be-defined set of magic bytes) that a message has been prepared and the URL where the message can be found.  Because Alice had to sign the transaction to send this message notification, it means that Qa (her public key) is now known and that the owner of address B has the required information to decrypt the message at the specified URL.  
----------------------

^^ This technique is apparently insecure.    

[Crowex]

Greg told me that this method is insecure, but I still don't understand why.  Like luv2drnkbr implied above, if you know the pubkey of the address whose owner you wish to message, why can't you use the Diffie-Hellman technique to derive a symmetric key (shared secret) with which you encrypt the message?:

----------------
If the public key for the bitcoin address you want to send an encrypted message is known, then you can.  

 The main problem is that when you are doing the initial public key exchange in order to get a shared secret and establish a secure channel, then if you are doing this key exchange over an insecure channel, then a man in the middle could replace both Alice and Bob's public keys with ones to which he holds the private keys. Then Alice and Bob think they are talking to each other but Mallory is decrypting Alice's message, changing it if he wants and re-encrypting it with the key he has sent to Bob and doing the same with the return messages.

 It is the problem of how you perform the initial authentication and how Bob knows that the public key is from Alice in order to establish a secure channel if you don't have a secure channel in the first place. This is why this technique is not secure unless maybe you use a PKI to authenticate people in the first place but then you must place your faith in a trusted third party and you must establish a secure communication channel with them in the first place.
 Or maybe you have another method of communication to cross check the public keys but then you need to know how secure this other method is.
 Authentication is a major problem especially if you want to mix it up with anonymity.

 If you know that you want to send a message to the owner of a certain bitcoin address and you know the public key then one identity is authenticated. So Bob knows what Alice's public key is because he knows Alice has signed a transaction with the private key corresponding to that public key.
 In this situation you can perform a key exchange over an insecure channel and Bob will know that he has established a shared secret with Alice and he is communicating with the private key holder for that address. Alice has received a public key over an insecure channel and won't really have any idea who she might be talking to.