One option would be to write a custom zk-SNARK "circuit" to support signing via a zaddr. This would
be a large amount of work and was dismissed, reasonably, as not viable by Zcash developers.
Daira discovered/invented a way to use the normal "spend circuit" of Sapling addresses to support this use case.
This means no special zkSNARK math or Rust code is needed, we can re-use all the existing code which verifies
a Sapling zUTXO is spendable.
Originally it was thought that a full Sapling SpendDescription (Zcash Protocol S4.4) would be needed, essentially all the parameters that are
used in a Sapling spend. But it was found that to support this use case, some data can be ignored or set to zero, so a zsignature consists of four units of data
* nullifier for the input Note (zutxo)
* rk, randomized pubkey of spendAuthSig
* zkproof (a librustzcash::Groth zero-knowledge proof)
* spendAuthSig, as specified in Zcash Protocol S4.13
This is exactly a normal SpendDescription with `cv=0` and `rt=0` which are not needed in this signing use case. This brings
the data size of a "zsig" to 320 bytes (before base64) and 428 bytes after base64 encoding.
The point of `z_signmessage` is to create a "fake" Sapling Note (zutxo) of a non-zero amount, and then generate these four
units of data, a subset of a normal SpendDescriptoin, then serialize these four units of data, then base64 encode and a string
of this base64 encoding is returned. This emulates exactly the workflow of `signmessage` from Bitcoin and Zcash transparent addresses.
Similarly, the design of `z_verifymessage` is to deserialize these 4 units of data, store them correctly in appropriate variables
of the appropriate datatypes, then pass these values to the XXX librustzcash function to detect if it's a valid Sapling Spend.
In this use case, Alice would sign a message that contains her zaddr as a string, such as:
My name is Alice and my address is zs1...
and Bob could use `z_verifymessage` to authenticate that the person who signed that message is the same person who owns the private key of `zs1....`. This prevents an entire class of attacks the author calls "zphishing", which will be described below.
## zphishing
What is zphishing? Firstly, what is phishing? One good definition is:
(noun) The act of circumventing security with an alias.
### Zphishing Scenario
Alice and Bob are using the encrypted memo field to talk back and forth. Additionally, Alice often gives
a Reply-To address to her memos, so various of her contacts know the same zaddr. This is a common scenario
currently as ZecWallet and all Zcash GUI wallets do not allow users to choose the Reply-To address to give
to each contact.
Charlie is one of Alices contacts that she has talked to, and knows her zaddr. Now, Charlie wants to pose
as being Bob, and via out-of-band means, knows or suspects that Alice and Bob are talking.
Charlie can send a memo to Alice pretending to be Bob, and give their own zaddress to Reply-To. The truly
anonymous nature of the memo field means that you really cannot authenticate *who* sent you the memo. This
is the shielded transaction equivalent to shady emails that look just like the official Bank/etc email.
