Fetching blocks for memos should not reveal what tx's a user is receiving

[holmesworcester]

Right now, a malicious lightwalletd, or anyone that can view a lightwalletd's network activity, can link transactions to a given recipient. This could be used to deanonymize a user, by linking them a to a transaction for which their identity is known. Here are some options.

1. Let zecwallet-light-cli fetch a block over a separate Tor circuit, whenever it needs to retrieve a memo. (In this case, it's important for the code that fetches these blocks to not contain anything about the user's state, since that could also be used by a malicious lightwalletd to profile a user and link transactions. For example, it should receive a block id and the address of the lightwalletd, create a new Tor circuit, fetch the block, and terminate.)
2. Give the user or wallet developer a setting that lets them designate their own tool for fetching blocks. Then they can build their own tool for fetching blocks that functions this way.
3. Give the user or wallet developer a setting to disable the fetching of any blocks. (Does this exist already?) Then zecwallet-light-cli could simply fail to return memos, and let the user or wallet developer fetch and decrypt memos themselves.
4. Implement SealPIR on the cli and lightwalletd side, as discussed here: https://github.com/zcash/zcash-android-wallet/issues/166

Option 3 is probably the easiest, but it's not ideal for the wallet developer, since they won't be able to rely on zecwallet-light-cli for state anymore, since they'll have to store their own state for transactions and memos, and make sure this matches the state provided by zecwallet-light-cli.

I'd say option 2 or 4 is the best place to start. Interested to hear more about this.

[holmesworcester]

Updated to reflect this discussion here: https://github.com/zcash/zcash-android-wallet/issues/166

[gmale]

Option 2 should be very straight forward to implement as a setting. On the mobile side, I'd estimate that as an hour of work because it basically boils down to reverting to how things used to work before "enhancing" transactions with memos was a thing.

Give the user or wallet developer a setting that lets them designate their own tool for fetching blocks. Then they can build their own tool for fetching blocks that functions this way.

Also:
In general, rather than "fetching blocks" we might want to phrase it as "fetching memos" or "fetching compact blocks" or even "fetching compact transactions" because, in most cases, light clients will probably not want to fetch entire blocks. Rather, they'd like to fetch the smallest feasible thing, which might be transactions or CompactTx objects.

[gmale]

Do you think "connect to the P2P network to fetch memos" should be included in this list, since it has been discussed a bit?

[holmesworcester]

Yeah, if fetching and parsing all blocks is an option, sure. (Or if full nodes can support PIR)

…

On Oct 1, 2020, at 7:53 PM, Kevin Gorham ***@***.***> wrote: Do you think "connect to the P2P network to fetch memos" should be included in this list, since it has been discussed a bit? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUFLR75XJI256E4WQWVITSIUI6LANCNFSM4SA2EAEA>.

[holmesworcester]

The skepticism I've heard around connecting to the p2p network is that we don't know what kind of attacks that exposes the user to.

I believe @defuse expressed this concern.