Prove that xpub matches xprv?

Question

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?)

Answer 1

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