4.8 KiB

Raw Permalink Blame History

HIP304 - z_signmessage + z_verifymessage

  HIP: 304
  Title: Signing and verifying messages from Sapling addresses
  Author: Duke Leto
  Category: Standards
  Created: 2020-02-02
  License: GPLv3

Terminology

The key words "MUST", "MUST NOT", and "MAY" in this document are to be interpreted as described in RFC 2119. [#RFC2119]

Abstract

This is HIP304 describing signed Sapling messages, allowing authenticated delivery of memos.

Motivation

TLDR: Extend the signmessage and verifymessage RPCs to Sapling shielded addresses. Many people, including the author, have created Github issues asking for the ability to sign messages with zaddrs. Originally, it was not possible with Sprout addresses but now Sapling zaddrs have the internal machinery to support this use case.

Specification

This document specifies two new RPCs

z_signmessage
z_verifymessage

which are direct shielded counterparts to the original Bitcoin RPCs:

signmessage
verifymessage

This specification is directly influenced by various Zcash Github issues and ZIP304 such as https://github.com/zcash/zcash/issues/3159 and https://github.com/zcash/zcash/issues/1770 and the algorithm designed by Daira and other Zcash developers. We simply took the publicly defined algorithm and decided to actually implement it and decide any implementation details that would be needed along the way.

Internal Design

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

.. [#RFC2119] Key words for use in RFCs to Indicate Requirement Levels <https://tools.ietf.org/html/rfc2119>_ .. [#BIP32] Hierarchical Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>_

4.8 KiB Raw Permalink Blame History