Topic: Encrypting messages question (Read 395 times)

Gaaaaawd the level of frustration!

So close any and so far away.

Here where I'm at:

(I'M using Bitcoin Core 0.20)


I can be done for sure, but how? (Details in OP)

Let's fix it!

Thanks for the heads up... yeah, was typing slower than I was thinking and my brain had already moved to the "one way hash" part of Pubkey -> Address which is where the OP seemed to be getting stuck

I've corrected it now.

Hashing and encrypting is something completely different.
Hashing is a one-way function. Easy and fast to calculate the hash of an input, but practically impossible to calculate the input out of the hash.

An encryption on the other hand can be reversed by knowing the corresponding key. Since you were referring to asymmetric encryption, the necessary key here is the private key while the public key is used to encrypt the message.




Correct.




Correct.



They do not "mean the same thing".
On a technical level, addresses don't exist. They are made for humans.

And yes, the address can be derived from the public key by using the corresponding hash function(s).




Because messages are signed with a private key and verified by the public key.
Messages are encrypting with the public key and encrypted with the private key.

You can not use the address, because you can not get the public key out of the address. Only the other way around (public key -> address via one-way function).

Not sure how do I explain this, technically you can actually use bitcoin address to encrypt a message, but only in symmetric encryption fashion, what you need here is asymmetric encryption (Publick Key encryption), bitcoin address is ripemd-160 bit hash of the public key which is 256 bits, so in short, the address and the private key are in a different format and thus the encryption algorithm won't work on the address, in the box example you would imagine the address as a very small box that can't handle the coin nor the lock.

So if you now understand that the address in its simplest form can't be used, you might still ask, well if the address is hash for the public key why can't we encrypt it? first of all, just because you know the address, and you know it's the hash of a public key, you simply can't reconstruct the public key from the address.

also after reading this part again


It seems like you are confusing encryption to a signature, ECDSA is designed for signature and shouldn't really be used for encryption anyway, there are far better options that were designed for the sole purpose of message encryption.

I know you know and that you've just made a typo, but for the sake of other users reading this thread, private key to public key is via a one way elliptic curve multiplication, not a one way hash.

As above. The public key is not a hash of the private key, and therefore the address is not a double hash of the private key. Incidentally, to calculate the address from the public key (where we do use hashing functions), we use two different functions - first SHA256, then RIPEMD160.

Correct.
If you mean deriving both then yes. But it's important to note that your address is derived from the public key and not the private key.
They don't. Address is a public key hash.

For ECDSA signatures to work, they need the public key to be able to validate the signature or to decrypt the message (in the case of ECIES). The addresses are a totally new format that is created by one of the earlier Bitcoin contributors and is not a product of the development of ECDSA.

An address is useless in the encryption of the message since it is not an ECDSA public key. The main point is: You need the public key. Yes, you can derive the address from a public key but you can't go the other way around. It's just like you can use flour to bake a cake but you can't use the cake to make flour; it's irreversible.

First of all, a thank you for making this post. It was really nice explanation.


Both public key and address are texts that no one can do something to steal your coins.

Both public key and address begin from the same string (private key)

Both public key and address mean the same thing. (If you have the public key you can make the address)

I just don't get why we can't use the address as ”The Box”.

For starters, you should forget about bitcoin address, imagine it doesn't exist, think of it simply as a different representation of a public key, next you need to understand basic Public-key cryptography, the simplest way to look it is by imagining a scenario where you need to send your friend something as a gift, say it's a gold coin, you are going to send it using a third-party which you don't trust, that coin is so expensive and you are afraid that somebody will steal it, so you decide to put that coin in money/cash box and send the whole box to your friend, you can simply purchase a new box, send the key and the box together (a terrible idea) or send the lock and the key separately (a bad idea)or a better way would be asking your friend to buy the box and send it to you (unlocked) and of course, he will keep the keys.




So now you put that coin in the box, and then you lock it (notice that you don't need the key to lock the box, but you need the key to unlock it) and then send it via an untrusted medium.





Your friend gets it and he uses the keys (since it's his lock and only he has the keys - not even you have the keys) and bingo, the coin arrives safely.

The box = Your friend's public key ( he can safely share it with others)
They keys = Private keys (He must not share it with others)
The coin = The encrypted message (The transporter knows there is something inside the box, but he doesn't know what that is)

You can't skip any part of those three.




Well actually the address is more like hash(hash(hash(private_key))), you need to hash the public key twice first using sha256 and then ripemd160, but you are correct, your friend doesn't need you to send him the public key nor the address, using his private key he knows what is the public key as well as the address, but YOU need HIS public key to encrypt a message which then he can decrypt using his private key.

Yes but I'm trying to say that if a person can decrypt the hash(private_key) (which is the public key), he can do it for the hash(hash(private_key)) too. (which is the address)

Because, as the others have mentioned, there is simply no way to get the public key from an address... (ignoring that you could go trawling through the blockchain for transactions where that address was used to provide an input, and get the public key from the transaction data).

Private Key -> ONE WAY hash elliptic curve multiplication -> Public Key -> ONE WAY hash -> Address

You can only go from left to right... you can't go the other way. If the person you're attempting to send the message to doesn't provide the public key, there is no way to encrypt the message so only their private key can decrypt it.


EDITED for the sake of correctness.

I don't know a thing about encryption.

Isn't like the hash but it's not one-way?

Example:

SHA256(message + address)

if(manymanyhashes(privkey) == submitted_address)
then print the message.

Hmm, I didn't write it well. It's probably not like hash.
The eliptic curve math is far away to understand it, based on my knowledge. As far as I've seen it it's like xy.

Private key is xy and public key is -x-y?

You can't skip the first step. How are you going to encrypt the message then!
In asymetric encryption, a key pair is needed. a public key known to everyone used to encrypt the message and a corresponding private key known by only the one who generated it and the only one supposed to decrypt the message.
Asymetric encryption solves the main problem with symetric encryption (where one key is used for both encryption and decryption) which is how to safely share the key without being intercepted by a malicious party.

Right now, the encryption thing goes like that:

1) I ask a guy to give me his public key.
2) I encrypt a message
3) I send him the encrypted message.

Since only if he owns the address, he can decrypt the message, why can't we simply skip the step 1?

^^ no, it won't work. As you can see, you need the public key not the address to encrypt a message.
You will have to ask the one you want to send the encrypted message to to give you his public key or do what ranochigo suggested since there is no other way to retrieve a public key from an address.

No, I mean that one:


Instead of writing the public key, to write the address.

What do you mean by inserting an address and what for?
If you mean to import it into Electrum then yes, it's possible. But it will only create a watching-only wallet that can be used to monitor the addresse's history/activity.
Using a watching-only wallet, you will not be able to sign or encrypt messages if this is what you want to achieve.

Its not. You can't get a public key from an address as an address is a hash of the public key. Since the hash is a one way function, you can't get the ECDSA public key from an address.

The main trick that people tend to use is to obtain the public key from a transaction that spends UTXOs from that specific address since the script would reveal its public key.

About electrum:

Can I somehow insert the address itself and not the whole public key? It asks me the public key and it is a small procedure to get the public key from an address.

Elliptic Curve Integrated Encryption System or ECIES for short. it is defined in the Standard For Efficient Cryptography 1 section 3.8 and i believe that is the algorithm that Electrum uses too.
here is a wikipedia link: https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

Oh... I now got it... Only the person with the public key's private key can decrypt it. No one else.


I encrypted this to my personal address' public key: 02ce99b57451cd90aef6bd8028df82bd7fbbfea93b40f4da45d13a4b401ae367f0

So, right now I can only know what's there

Thanks @ranochigo. Does this way of encryption have a name? Like SHA256 (for hash)