Diffie-Hellman key exchange is a key negotiation mechanism to agree on a common key between two parties using an insecure channel. How can you do a key exchange between two values both available to you?
Both values are not available to the party you want to communicate with. If you were to transmit both values, then someone could intercept them and know the secret as well.
Sender: has TX private key r ("sender's random data" in CN WP) & recipient public view key A.
Recipient: has TX public key R (published on the blockchain) & recipient private view key a.
Product will be the same. You can get the shared secret as either rA or aR.
Where's the money? Money resides on one-time key P (AKA "output"), deterministically constructed from the shared secret and the recipient's public spend key.
The sender is communicating the R and the P via insecure channel - the blockchain. Anyone can see R and P, but only the one knowing both the shared secret and the public spend key will be able to recognize the funds. To spend, he would need the private spend key. Why can he recognize the funds? Because the Ps are deterministically made from shared secret. The sender just computes the aR, generates some P, and if it matches the one in the TX - it must be for him.
It's important to understand that one-time keys are all that exists on the blockchain. An address is nothing but an instruction to sender, allowing him to use the DH to construct such output which only the intended recipient can decode and spend. The address is never recorded to the blockchain.
I thought the recipient's address is public and therefore no connection is required.
The address is public. Since it's really an instruction, and following the instruction requires some "random data" as an ingredient, nobody can ever tell which instruction was followed to create a particular one-time key (AKA "output") on the blockchain.
Also, if there is a DH between the sender and the recipient how is that anonymous?
Because what happens is that nobody knows who the "message" is for (message being the output in any TX) unless he's able to reconstruct a match - which means it's either for him, or he's the one who sent it. Anyone receiving needs to take the R, pretend all outputs are "for him" and see if he gets a match. That's also the reason wallet scan takes time.
Where is the other party?
Other party is the recipient.
Where is the insecure channel?
That's the blockchain.
Also, why not use just a simple hash of those two values?
Actually, it's used. Look at how outputs are constructed:
P = H_s(rA||i)G + B
H_s is the hash function, r is the TX private key randomly generated by the sender, i is output index in the TX (0, 1 ...), and B is the recipient public spend key. Note that recipient address is made of A and B.
Send & Receive Process
Here's a step-by-step:
- Recipient asks the sender for payment and transmits his address to the sender. That's the two public keys A & B. Suppose Eve is listening on that communication - she now knows the address being transmitted.
- Sender generates some random r which will be used as private TX key.
- Sender calculates the public TX key by multiplying the r with elliptic curve base-point. R = rG. This goes into TX header, and will be published on the blockchain with the TX. Eve is of course monitoring the blockchain, and now she has A, B, and R.
- Sender calculates the P which will hold the funds. P = H_s(rA||i)G + B.
- Sender publishes the TX with the R and P to the blockchain. This is practically what defines your TX output side. The rest of the data is the signature & key image. This is all that's recorded. Notice how there's no recipient address :)
- Here's where DH happens. The recipient will need to try and reconstruct the P, but to do it he needs all the parts. All parts but one are public, and Eve will also know all of them. Thing is, the recipient doesn't know the last bit (the r) and neither does Eve. Without the r, the recipient could be anyone as hash function makes the output look like it's just some random number, same like any other. However, the recipient doesn't need the r as he knows another secret (his private viewkey a) and he can use it instead. The recipient takes the R and i from the TX, does P' = H_s(aR||i)G + B, and if it matches the one in the TX, ka-ching.
So, without the last secret ingredient, Eve remains clueless. She knows that I gave you my address. She knows about all TX-es on the blockchain. She can't tell whether I ever received anything to that address.
If I, the recipient, leak my a to Eve, she can check the entire blockchain and see all TX-es I received. If you, the sender, leak your r to Eve, she can only check a particular TX against some address and see if it's a match. So, thanks to DH, we both get to keep our secrets but are able to safely communicate the following info "this output was made for you".
