From cafd6d83da25fa0d0e0a4e27a0bf2faa8dd4c256 Mon Sep 17 00:00:00 2001 From: Duke Leto Date: Sun, 2 Feb 2020 11:00:46 -0500 Subject: [PATCH] Lots mo beef --- hip-0304.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/hip-0304.md b/hip-0304.md index 714d3b1..94601c5 100644 --- a/hip-0304.md +++ b/hip-0304.md @@ -48,6 +48,57 @@ would be needed along the way. 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. + + + + + # References