<p>No. That is impossible if A and B have never communicated through a secure channel to exchange keys before, unless you are willing to trust another user, for example a user, D, you know and have safely exchanged keys before, that says it trust users B address, creating <a href="http://en.wikipedia.org/wiki/Web_of_trust" rel="nofollow">a web of trust</a> or less preferable a <a href="http://en.wikipedia.org/wiki/Certificate_authority" rel="nofollow">certificate authority</a>. This is a known and significant issue in public key exchange.</p>

CC BY-SA 3.0
2014-02-24T15:07:17.260Z
Nothing is "impossible". It might be impractical, but that is different. After posting I discovered the Diffie-Hellman key exchange, which seems to contradict what you state.
T9b
CC BY-SA 3.0
2014-02-24T16:04:26.063Z
You might want to check again what Diffie-Hellman key exchange is meant for. D-H guarantees secrecy of communication without prior key exchange, but not authentication of the third party. So you might be securely exchanging keys with a man in the middle!
dendini
CC BY-SA 3.0
2014-02-24T16:12:26.783Z
Exactly dendini. You cannot know if the key belongs to the person you think it belongs to, unless you use something like a web of trust, but that has its issues too.
Jori
CC BY-SA 3.0
2014-02-25T13:21:13.590Z
I beleive that Authenticated or Unified DH (aka DH2) does get around this problem - but I am open to this kind of advice.
T9b
CC BY-SA 3.0
2014-02-25T16:58:16.573Z
I highly doubt that. There is no solution, as there is no way to identify the person at the other end of the network, without having a secure channel before (just once is enough).
Jori
CC BY-SA 3.0
2014-02-26T13:26:47.720Z
Authentication is a very hard problem. CAs are an attempt at authentication but see my comment to @Charlie.
zaph
CC BY-SA 3.0
2014-02-24T13:24:52.767Z
2014-02-26T10:15:29.433Z
2014-02-26T10:15:29.433Z
Jori
<p>Email is a very bad way to exchange address information unless the email is digitally signed. If it was A would still need to know which key to use to validate the signature on the email.</p>

<p>A typical secure scenario would be if B is an ecommerse site and wants to tell A where to send the Bitcoins they would do so on a secure webpage over SSL. The identity of B is therefore validated by there SSL certificate. If C tried a man in the middle attack then an error would appear in A's browser.</p>

<p>That does rely on C not being able to corrupt the SSL certificate issuing process. That's a fairly safe assumption if C is a criminal gang. If C is a well financed government agency may be not.</p>

CC BY-SA 3.0
2014-02-26T13:24:18.160Z
There is a flaw in that we tend to blindly trust certificates, just because there is a cert that has a chain of trust to a recognized CA does not mean it belongs to who you think it does. So, one is careful ad looks at the cert, looks at the Common Name, is that the correct name? You want to connect with company you know as "ABC". Should you trust a cert with the Common Name "ABC Inc.", "ABC", "ABC LLC"? And, really how many people even look at a cert. There is a difference between "validating" a cert and validation an identity. Secure apps use SSL pining but you need the cert in the app.
zaph
CC BY-SA 3.0
2014-05-27T18:02:50.713Z
To be fair with the EV certs (the ones that make the address bar go green) they are fairly well validated. Theres a standard the issuing authority is supposed to follow to validate you. Its pretty rigours. Of course it relies on the issuer playing by the rules, which they generally do. But I am sure a really well financed attacker could find a way.
Charlie M
CC BY-SA 3.0
2014-05-27T18:10:20.423Z
I agree with your comment. There are a few issuers however who are not rigorous, I know my wife deletes some CAs from her computer that she does not trust (she is professionally paranoid).
zaph
CC BY-SA 3.0
2014-02-26T07:09:31.113Z
2014-02-26T07:09:31.113Z
Charlie M
<p>Let's say you have person A who wants to pay person B.</p>

<p>A common way for B to communicate his/her address to A is by QR code or email or some such non secure method either of which could be substituted for another address in a man-in-the-middle attack, by person C. In other words C contrives a situation where they can replace B's address with their own, thereby making A pay C instead of B.</p>

<p>This would be even harder to prevent if A and B were continents apart. Not only would A not be able to see B or perhaps even talk to them, but they would also have some difficulty carrying out even basic checking.</p>

<p>Is there a way to stop a man-in-the-middle attack when communicating addresses in this sort of circumstance?</p>

CC BY-SA 3.0
2014-02-24T20:03:48.967Z
Your question is ill-defined. You say "who wants to pay person B" but what does that mean? In order to "want to pay person B", there must be something you know that identifies person B, and the answer to this question 100% depends on what that something is. For example, if you know you want to pay "Jeffrey Smith, who currently resides at 112 Buckingham Lane" that's totally different from "Amazon, the merchant who owns amazon.com" or "the guy who just sent me this email".
David Schwartz
CC BY-SA 3.0
2014-02-25T13:25:17.250Z
It means that you want to pay another person. It is a pre-amble to a payment, but for the sake of clarity, it is not A who should know anything about B, but the other way round. If B is requesting a payment, they must already know something about A, and from that a secure and authenticated shared secret can be agreed.
T9b
CC BY-SA 3.0
2014-02-27T21:46:17.943Z
You want to "pay another person", but what does that mean? How do you know which person is the person you want to pay? Do you know their name? Address? National identification number? You can't answer the question without understanding what it is that uniquely identifies who you want to pay. Otherwise, there's no way to know whether you've paid the right person or not. And you can't assure something you don't even understand.
David Schwartz
<security>
Is there a way to stop a man-in-the-middle attack when communicating addresses?
T9b
# Is there a way to stop a man-in-the-middle attack when communicating addresses?

(Asked by: username_0 on 2014-02-24)

Let's say you have person A who wants to pay person B.

A common way for B to communicate his/her address to A is by QR code or email or some such non secure method either of which could be substituted for another address in a man-in-the-middle attack, by person C. In other words C contrives a situation where they can replace B's address with their own, thereby making A pay C instead of B.

This would be even harder to prevent if A and B were continents apart. Not only would A not be able to see B or perhaps even talk to them, but they would also have some difficulty carrying out even basic checking.

Is there a way to stop a man-in-the-middle attack when communicating addresses in this sort of circumstance?

**Tags:** security

> **Comments:**
> **username_1**: Your question is ill-defined. You say "who wants to pay person B" but what does that mean? In order to "want to pay person B", there must be something you know that identifies person B, and the answer to this question 100% depends on what that something is. For example, if you know you want to pay "Jeffrey Smith, who currently resides at 112 Buckingham Lane" that's totally different from "Amazon, the merchant who owns amazon.com" or "the guy who just sent me this email".  
> **username_0**: It means that you want to pay another person. It is a pre-amble to a payment, but for the sake of clarity, it is not A who should know anything about B, but the other way round. If B is requesting a payment, they must already know something about A, and from that a secure and authenticated shared secret can be agreed.  
> **username_1**: You want to "pay another person", but what does that mean? How do you know which person is the person you want to pay? Do you know their name? Address? National identification number? You can't answer the question without understanding what it is that uniquely identifies who you want to pay. Otherwise, there's no way to know whether you've paid the right person or not. And you can't assure something you don't even understand.  

---

## 2 answers

### Answer by username_2 on 2014-02-24. Score: 4

No. That is impossible if A and B have never communicated through a secure channel to exchange keys before, unless you are willing to trust another user, for example a user, D, you know and have safely exchanged keys before, that says it trust users B address, creating [a web of trust](http://en.wikipedia.org/wiki/Web_of_trust) or less preferable a [certificate authority](http://en.wikipedia.org/wiki/Certificate_authority). This is a known and significant issue in public key exchange.

> **Comments:**
> **username_0**: Nothing is "impossible". It might be impractical, but that is different. After posting I discovered the Diffie-Hellman key exchange, which seems to contradict what you state.  
> **username_3**: You might want to check again what Diffie-Hellman key exchange is meant for. D-H guarantees secrecy of communication without prior key exchange, but not authentication of the third party. So you might be securely exchanging keys with a man in the middle!  
> **username_2**: Exactly username_3. You cannot know if the key belongs to the person you think it belongs to, unless you use something like a web of trust, but that has its issues too.  
> **username_0**: I beleive that Authenticated or Unified DH (aka DH2) does get around this problem - but I am open to this kind of advice.  
> **username_2**: I highly doubt that. There is no solution, as there is no way to identify the person at the other end of the network, without having a secure channel before (just once is enough).  
> **username_4**: Authentication is a very hard problem. CAs are an attempt at authentication but see my comment to @username_5.  

---

### Answer by username_5 on 2014-02-26. Score: 0

Email is a very bad way to exchange address information unless the email is digitally signed. If it was A would still need to know which key to use to validate the signature on the email.

A typical secure scenario would be if B is an ecommerse site and wants to tell A where to send the Bitcoins they would do so on a secure webpage over SSL. The identity of B is therefore validated by there SSL certificate. If C tried a man in the middle attack then an error would appear in A's browser.

That does rely on C not being able to corrupt the SSL certificate issuing process. That's a fairly safe assumption if C is a criminal gang. If C is a well financed government agency may be not.

> **Comments:**
> **username_4**: There is a flaw in that we tend to blindly trust certificates, just because there is a cert that has a chain of trust to a recognized CA does not mean it belongs to who you think it does. So, one is careful ad looks at the cert, looks at the Common Name, is that the correct name? You want to connect with company you know as "ABC". Should you trust a cert with the Common Name "ABC Inc.", "ABC", "ABC LLC"? And, really how many people even look at a cert. There is a difference between "validating" a cert and validation an identity. Secure apps use SSL pining but you need the cert in the app.  
> **username_5**: To be fair with the EV certs (the ones that make the address bar go green) they are fairly well validated. Theres a standard the issuing authority is supposed to follow to validate you. Its pretty rigours. Of course it relies on the issuer playing by the rules, which they generally do. But I am sure a really well financed attacker could find a way.  
> **username_4**: I agree with your comment. There are a few issuers however who are not rigorous, I know my wife deletes some CAs from her computer that she does not trust (she is professionally paranoid).  

---

