Hi Noir team, great to see this, and good call putting the design out for review before building it.
I’ve been working on the same idea for OpenPGP Wallet and posted my design here on October 12: FROST 2-of-3 between a user's own devices for shielded ZEC (Ironwood)
Our two designs line up almost step by step (2-of-3, the phone as an independent checker, DKG, PCZT, sweep to a new vault after a loss). I read that as a good sign: the ZIPs and the ZF crates lead everyone to the same architecture.
Feedback on what you asked:
QR vs BLE. I’d make animated QR the default. It’s a real air gap with a tiny attack surface, it works between any two devices, and it needs no OS pairing state. BLE stacks have a long history of remote bugs, and in an MV3 extension you’d be fighting the platform. ZIP 312 wants the randomizer on a confidential, authenticated channel, so I encrypt the QR payloads with a key agreed at pairing (ephemeral keys plus a short code compared on both screens).
Round order. rk is part of the sighash and ZIP 312 derives each randomizer from the signers’ commitments, so the phone’s commitments have to exist before the PCZT is built (zcash/orchard#571). That means three QR scans rather than two.
Nonces in an extension. MV3 service workers get killed when idle, which makes it tempting to persist session state. Nonces should never land in chrome.storage.local or sync: a restored or synced nonce can leak a share. If the worker dies mid-session, restart the session.
Recovery. Restoring a lost share from its phrase keeps that same share valid on the lost device, so I’d make “sweep to a new vault” the default after any loss, not only the fallback. And as the first reply says, three phrases is a lot, and each one is a share at rest. I went with no phrase at all: the backup share is a file encrypted under its own key and passphrase, written to removable media and decrypted back before setup completes.
Two threat-model questions.
- How do you derive nk, rivk and qsk for the group today? As far as I can tell zcash/zips#895 isn’t merged, and zcash-sign uses a fork-only constructor that gives up quantum recoverability. Related: if every device holds qsk, can a single device spend on its own once quantum recovery is enabled? Worth stating either way.
- The update channel. If the extension and the phone app come from the same publisher, one compromised release pipeline or store account can push a malicious update to both signers at once, which is 2 of 3. That’s the software version of the reseller incident that started this. Reproducible builds and signed releases help, but the strongest fix is letting users pick co-signers from different vendors.
Which leads to a proposal. With Zkool, NoirWallet and OpenPGP Wallet all doing FROST for shielded ZEC, we’re heading for three signing protocols and three backup formats that don’t talk to each other. Would you be open to a common open spec for the coordinator-to-signer messages and the share backup format? A Noir phone could then co-sign for another wallet and the other way round, which also closes the single-vendor gap above. I’m happy to do the drafting and the test vectors.