[bisq-network/proposals] Use of a third party to unlock the maker's trade reserve (#278)

Steven Barclay notifications at github.com
Mon Nov 23 20:49:19 CET 2020


Thinking a bit more about some of the proposal details, it may be a bit more serious than I thought if the maker's computer can trick the third party into helping them sign a message with the private key _e_ plus an arbitrary offset _e'_. This is because in BIP32, every non-hardened private key has a known, public offset from its parent, so potentially a transaction could be signed with the wrong private key in the wallet (say outside the user's trade reserve) - a kind of related key attack. But as I mentioned, there should be fairly easy techniques to prevent this.

Also, I thought a bit further about the seed phrase setup idea, where the user's Bisq instance knows the words but not the order and his smartphone knows the order but not the words. As mentioned, this probably requires the use of garbled circuits to jointly derive the master private key in a secure 2-party computation. Unfortunately, it turns out that BIP39 key generation from a seed phrase uses password stretching internally - specifically PBKDF2 with HMAC-SHA512 and an iteration count of 2048. This would make running it inside a garbled circuit very expensive - I estimated roughly 700 million garbled AND-gates would be required, making the circuit (which is strictly single-use, like a one-time pad) about 35GB in size for 128 bits of security, which would need to somehow be transferred between either the smartphone and the Bisq instance (say using an SD card) or the Bisq instance and the third party. Even though generating and running the circuit is very fast, that is hardly practical for most users.

Luckily, due to some of the details of the iterative PBKDF2 stretching algorithm (namely that it XORs all its intermediates together to form the final result), it should be possible to carry out most of the computation outside the garbled circuit if an alternative wallet setup procedure is used: The Bisq instance inputs/creates a full, in-order 12-word seed phrase as it does currently. The smartphone (or other 2nd factor) inputs/creates a BIP39 passphrase of high entropy (say 80-128 bits) to use with the seed phrase. This is then encrypted (to a numeric code, say) and the user enters it into his Bisq instance to complete the wallet setup. It's vital that the BIP39 passphrase (which is distinct from the current optional BitcoinJ wallet encryption password) has very high entropy, as it won't benefit from the PBKDF2 stretching, due to the bulk of the 2-party computation taking place directly on the user's computer, outside the garbled circuit. This should result in a much reduced garbled circuit, say a few 10s of MB, which is hopefully small enough to practically transfer from the 3rd party server to the user's computer.

It's also much better I think, for maximal security, that the user verifies externally (say using Electrum or a hardware wallet) that his BIP39/BIP32-derived Bisq wallet actually corresponds to the written-down seed-phrase+passphrase, say by checking the chain codes or first few generated addresses. This is because a hacker could potentially control what's seen on the screen (of either device but not both) and trick the user into generating a wallet with the wrong seed-phrase/passphrase. This could open the user up to a blackmail attack, even though the attacker couldn't directly steal funds this way. I thought of a rather elaborate procedure by which the user could validate the wallet using both devices together (neither of which is trusted on its own), by doing some simple sums manually using pencil and paper, to transfer certain sensitive numbers from one device to the other in an one-time-pad-encrypted form. In this way, no device learns more about the seed-phrase+passphrase than it knew to begin with but is still able to validate the whole thing. (A validation from _both_ devices means the wallet is correctly set up in our threat model.) However, that procedure is probably a bit much to expect most users to follow, but could possibly be added as a special feature later.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/278#issuecomment-732387800
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20201123/0146fa91/attachment.html>


More information about the bisq-github mailing list