<p>No that is not possible as it will require reverse engineering the <code>HMAC-SHA512</code> function or finding a double collision that will generate the same keys. The <code>xpub</code> key is an encoded form of the extended key which is basically the concatenation of the public key and chain code at the account level. You include this extended key along with an index number (0 for receiving and 1 for change) into the <code>HMAC-SHA512</code> function to get a child extended key. This child extended key will be fed again into the <code>HMAC-SHA512</code> function again along with the index number (now this will be incremented sequentially to generate number of addresses like 0, 1, 2...) to display the addresses. </p>

<p>Now to achieve a situation that you mentioned, the attacker will have to create a <code>xpriv</code> in such a way that the corresponding <code>xpub</code> when passed through the SHA512 function twice (with the same index numbers) will generate the first address identical to yours, but different after you increment the index numbers. This means, the attacker will have to find two collisions to get the same first address. This is an impossible feat.</p>

<blockquote>
  <p>But since the printed xpub QR code necessarily transited several untrustworthy (i.e. online) computers before reaching paper, how can I be sure it wasn't tampered with in transit?</p>
</blockquote>

<p>When you import such extended key into a web server or an online application, you should generate some addresses and check they match the addresses you generated on your air gapped device to see that the service/server was not compromised when importing the <code>xpub</code></p>

CC BY-SA 4.0
2019-08-07T13:01:21.803Z
2019-08-07T13:01:21.803Z
Ugam Kamat
<p>I'm researching a paper wallet system where I generate an HD xpub/xprv
using an offline laptop. I write down the xprv by hand. I capture the
xpub via QR code using my phone, to transfer to an online full node.</p>

<p>One potential attack vector is to replace the receiving addresses with
addresses under the attacker's control. To combat this, I plan to
print out the xpub as a QR code, and occasionally using the offline
laptop (which has no state), scan it in and generate a new batch of
receive addresses which I can then manually verify match those created
by the full node.</p>

<p>But since the printed xpub QR code necessarily transited several
untrustworthy (i.e. online) computers before reaching paper, how can I
be sure it wasn't tampered with in transit?</p>

<p><strong>Question</strong>: if I generate a single receive address (e.g. m/0/0), send
some small amount of BTC to that address, create a PSBT withdrawal
using the online node, then successfully sign that using the xprv on
the offline node, is that sufficient to prove that the xpub is
authentic?</p>

<p>In other words, is it feasible that an attacker could modify the xpub
such that m/0/0 matches my xprv, but (e.g.) m/0/1 matches the
attacker's xprv? (And if that is feasible, how might I validate that
the printed xpub matches the xprv for all possible addresses?)</p>

<security><paper-wallet>
Prove that xpub matches xprv?
Bitcoin Hodler
# Prove that xpub matches xprv?

(Asked by: username_0 on 2019-08-07)

I'm researching a paper wallet system where I generate an HD xpub/xprv
using an offline laptop. I write down the xprv by hand. I capture the
xpub via QR code using my phone, to transfer to an online full node.

One potential attack vector is to replace the receiving addresses with
addresses under the attacker's control. To combat this, I plan to
print out the xpub as a QR code, and occasionally using the offline
laptop (which has no state), scan it in and generate a new batch of
receive addresses which I can then manually verify match those created
by the full node.

But since the printed xpub QR code necessarily transited several
untrustworthy (i.e. online) computers before reaching paper, how can I
be sure it wasn't tampered with in transit?

**Question**: if I generate a single receive address (e.g. m/0/0), send
some small amount of BTC to that address, create a PSBT withdrawal
using the online node, then successfully sign that using the xprv on
the offline node, is that sufficient to prove that the xpub is
authentic?

In other words, is it feasible that an attacker could modify the xpub
such that m/0/0 matches my xprv, but (e.g.) m/0/1 matches the
attacker's xprv? (And if that is feasible, how might I validate that
the printed xpub matches the xprv for all possible addresses?)

**Tags:** security, paper-wallet


---

## 1 answers

### Answer by username_1 on 2019-08-07. Score: 3 | Accepted answer

No that is not possible as it will require reverse engineering the `HMAC-SHA512` function or finding a double collision that will generate the same keys. The `xpub` key is an encoded form of the extended key which is basically the concatenation of the public key and chain code at the account level. You include this extended key along with an index number (0 for receiving and 1 for change) into the `HMAC-SHA512` function to get a child extended key. This child extended key will be fed again into the `HMAC-SHA512` function again along with the index number (now this will be incremented sequentially to generate number of addresses like 0, 1, 2...) to display the addresses.

Now to achieve a situation that you mentioned, the attacker will have to create a `xpriv` in such a way that the corresponding `xpub` when passed through the SHA512 function twice (with the same index numbers) will generate the first address identical to yours, but different after you increment the index numbers. This means, the attacker will have to find two collisions to get the same first address. This is an impossible feat.

> But since the printed xpub QR code necessarily transited several untrustworthy (i.e. online) computers before reaching paper, how can I be sure it wasn't tampered with in transit?

When you import such extended key into a web server or an online application, you should generate some addresses and check they match the addresses you generated on your air gapped device to see that the service/server was not compromised when importing the `xpub`


---

