Specify security interactions between Sapling Viewing Keys and Payment Disclosures

[nathan-at-least]

Viewing Keys and Payment Disclosures are very likely to interact in security properties and these need to be well documented.

Some questions, which assume a "Viewing Key Holder" does not know the associated spending key:

• Can a Viewing Key Holder produce a Payment Disclosure for any payment revealed by that Viewing Key?
• Does a Payment Disclosure Recipient have any guarantee about the "originating key / capability" of the Payment Disclosure? For example, can they correctly believe "this PD was originally generated by someone who knew the associated Viewing Key."
• Do either of the above depend on whether or not the VK Holder holds the VK of the receiving or sending address versus whether or not the PD generator knew the sending or receiving address?
• Are there unexpected edge cases that would violate a user's mental model of either VK or PD properties due to their interaction?

A brainstorm about the last question: in #292 there's a documented edge case where invalid ciphertext is sent on chain to violate a completeness property of Viewing Keys. Could a separate PD be generated for such a transfer? If so, what expected or stated properties might be violated about either VK or PD?

[daira]

There is no specification for payment disclosures. (They are implemented for Sprout but not for Sapling, and never graduated from "experimental" for Sprout.) Because of that I'd actually say it was premature to consider interactions, and we should not block viewing keys on answering these questions. In general we can't block prioritized features on potential interactions with other features that haven't been prioritized, or we'll never make progress.

@str4d considers some possible designs for Sapling payment disclosures in https://forum.zcashcommunity.com/t/z-addresses-usage-analysis/35497/9 . If a payment disclosure is a non-interactive proof, then it is transferrable and so does not prove that the party presenting it has made the payment, only that the payment was made. I'll assume this is the case, since otherwise we would need an interactive protocol.

Can a Viewing Key Holder produce a Payment Disclosure for any payment revealed by that Viewing Key?

Yes, because the payment disclosure is just a proof that the payment was made, and a viewing key holder has all the information needed to prove that.

Does a Payment Disclosure Recipient have any guarantee about the "originating key / capability" of the Payment Disclosure? For example, can they correctly believe "this PD was originally generated by someone who knew the associated Viewing Key."

There are possible designs that would prove that, and designs that would not.

Do either of the above depend on whether or not the VK Holder holds the VK of the receiving or sending address versus whether or not the PD generator knew the sending or receiving address?

Probably not.

Are there unexpected edge cases that would violate a user's mental model of either VK or PD properties due to their interaction?

This is a very open-ended question. I don't know of any. The accessible information is just the union of the information provided by the viewing keys and by the payment disclosures, as you would expect. It will be important to communicate that a PD is only a proof that a payment occurred. There may be other names that would communicate that better.

[daira]

I've reserved ZIP number 311 for specification of Sapling payment disclosures.