Zcash needs an answer to crypto’s standard “Connect Wallet” flow: a user visits a site, clicks a button, and logs in by signing a message with their key. Ethereum pioneered this, now it’s everywhere. The Zcash web wallet library cannot yet do this, because the standard does not exist.
It sounds like there is broad support for removing T-addresses from UAs.
Is this a good opportunity to also make any adjustments that might be needed to support signing and verifying messages?
Disclosure: I am not a cryptographer, I am web app developer. It is my understanding that the materials included in UAs currently do not contain enough information to verify an (Orchard) signature, but I might be wrong on this.
Given a user’s Zcash address, anyone should be able to:
Verify messages signed by that address.
Encrypt messages to that address. (off-chain presumably)
Zcash address holders should be able to:
Sign any statement (this is “Connect Wallet”)
Decrypt messages encrypted to that address.
This unlocks a ton of utility including:
Signing into a website using a Zcash address (see Uniswap, NEAR Intents)
Messaging apps like Signal that encrypt to an address holder off-chain
Sending encrypted files to an address holder
Voting / DAO governance based on address signatures
Signing git commits, making verified public statements, safe security disclosures
Cross-chain interactions (other chains verify the signature)
Knowing an on-chain memo came from a specific user (I know this is in the works, but the clearsigned text should be copy/paste-able, the signing keys and proving methods should be the same)
???, profit
How can we make this happen? Or is it already more possible than I understand with the current implementation?
Related threads involving thoughts on UAs and T-addresses:
Please do not conflate these two. Signatures and encryption are two very different primitives, and it is generally a bad idea to assume it is safe to use the same key material for both signing and encryption.
You’ve created a thread about signatures that are tied to addresses; please focus it on that.
Sure. I’m speaking from a user experience perspective: I essentially want PGP UX, which is far from perfect (or modern), but PGP UX for Zcash addresses, ideally signing and encrypting.
But if realistically we can only pull off signing on a shorter timeframe, that’s still great. I’d love for whatever encoding format in the “new UA” to support future extensions for encryption, like ASCII armor does in the PGP world.
I do not. PGP UX is terrible, and the general kitchen-sink approach to managing cryptographic keys is outdated and does not reflect modern best practices. There are many people who have written more on this topic, The PGP Problem | Latacora is the post I have most readily at hand.
Hundreds of thousands of people are using PGP right now on Tor, in the communities that propelled Monero to being number one. I don’t think that should be overlooked.
I need you to zoom out and see the user story here. instead of getting into the nitty gritty of implementation if you can - I think we get stuck on strong, technically-correct opinions around here a lot and miss the user completely.
I want a user to have something that they can share to receive messages, receive money, and to sign messages. Whatever that is, whether we call it an address or not, is what needs to exist.
Right now it could be:
(Zcash UA) + (Session Messenger public key - embedded in UA? if we delegate)
(Zcash UA) + (Signal username? if we delegate)
(Zcash UA) + (PGP Public Key? if we delegate)
All of those things above I have shared with people in multiple messages, it’s the only way right now.
I’d rather it be:
(Zcash UA v2) + (Embedded way to verify signed messages) + (Embedded way to send that user a message somewhere) [Architected by our talented team in our way rather than delegating]
This is incorrect; an Orchard address (or more generally, the Orchard receiver within a UA) is compatible with a signature protocol.
The thing that is missing is the signature protocol itself. Due to the way the shielded protocols work, an “Orchard signature” necessarily requires a full zero-knowledge proof.
ZIP 304 is partially instructive for how Orchard address signatures would work. However, rather than using the full Orchard Action circuit, we would craft a new circuit that just does what is needed (and is mostly but not fully a subset of the current circuit). This is doable and would result in a more efficient ZKP (thanks to us deploying Halo 2 for Orchard meaning that circuit changes don’t require a trusted setup), but technical and requires both sufficient time and cryptographic expertise to get right.
There’s a subtlety here that is also very important: a signature for one receiver within a UA is not a signature for that UA. You need signatures that bind the entirety of the UA: all of its receivers, as well as any metadata within the UA. So in addition to both ZIP 304 and a protocol for Orchard address signatures, you also need a protocol for Unified Address signatures that correctly builds upon the components while preserving the overall signature properties.
Great context thank you, and good point regarding needing to bind the entirety of the UA.
Perhaps we could designate some pool as the “Identity pool”? Say, Orchard is what we always use to sign messages, even after the pool is someday deprecated? Not ideal. The UX would have to show “signed by orchard receiver” instead of the more typical “Signed by crypto address / UA” flow people are familiar with too. Thinking aloud here, I appreciate your brain on this!
Edit: Or I suppose we could only allow signatures for UAs that contain a single receiver with no further metadata/receivers embedded, but that also feels confusing.
Is there a modern battle-tested (non-PGP) signing approach outside of the cryptocurrency world that you respect, with private keys that could potentially be derived from the user’s seed phrase, and somehow associated publicly as having been derived from that same seed phrase + embedded in the UA?
That does not match what people expect from an address signature.
It is also vulnerable to misbinding attacks. Anyone can mix-and-match receivers within a UA; if only the Orchard receiver is used for signatures, then depending on how signing is implemented it could be possible to swap out the other receivers for adversary-controlled ones, leading to potential user loss of funds.
Yeah, I was imagining something like a “ua1.*” standard that can only ever have one receiver in it, and only that can be used for signing. Not fun.
But with the “user hat” on: Everyone is used to signing into “Connect Wallet” experiences today with only one “key”, and that’s the weird challenge of UAs: they can have multiple “keys” embedded.
So for quickly enabling “Connect Wallet” signatures, logging in with one “key” rather than all of the receivers that could exist in an UA could be fine.