I am investigating on the security properties of the in-band encryption scheme (IND-CCA2 and IK-CCA) of ZCash and I was looking for a formal security argument for the key-privacy. Reading the Specs and this thread (https://github.com/zcash/zcash/issues/558), I got that key-privacy derives from the fact that the in-band scheme is ECIES-based and on the security properties of curve used. Is there any formal proof or properties I am missing? Thanks.

# On the security of Sprout/Sapling in-band encryption

The proof of key privacy for ElGamal in Appendix A of https://cseweb.ucsd.edu/~mihir/papers/anonenc.html is straightforwardly adaptable to half-static Diffie-Hellman in general, and the scheme used by Zcash in particular. This is folklore; I haven’t seen the proof completely written out anywhere.

Thanks Daira, for the answer.

I have continued to study the encryption scheme, and another questions popped in my mind: I have noticed that the set of input parameters of the KDF are different in Sprout/Sapling.

Reading the DHAES paper (https://eprint.iacr.org/1999/007), only the ephemeral public key *epk* and the shared secret *ss* are used as input, instead in Sprout also *pk_enc* and *hsig* are taken into account. I have read on the Spec that *hsig* allows to construct a randomness extractor from a weak-PRF (by using a result in sec 7 of https://eprint.iacr.org/2011/708.pdf). Instead, I have not found the rationale for adding *pk_enc*. In Sapling, *pk_enc* and *h_sig* are not used anymore (*h_sig* is not available since Joinsplit is separated in Spend/Output transfers). Since the min-entropy of the key exchange in *Curve25519* and *Jubjub*, should be roughly the same, is there a particular reason that justify that change? Thanks

Ps: maybe I should have opened a different thread

The reason for not including pk_enc in the KDF input for Sapling is to support diversified addresses. That is, pk_enc varies between diversified addresses for the same ivk, and so the KDF must not depend on it, in order for an ivk to be usable for decrypting ciphertexts to *any* corresponding diversified address.

The rationale for adding pk_enc to the KDF in Sprout was, if I remember correctly, that we believed it might be necessary for IND-CCA2 security and/or for post-quantum privacy (in the case where the quantum attacker does not have the public key). Actually it is not needed for either of those; for IND-CCA2 this follows from the DHAES security proof, and for post-quantum privacy see https://github.com/zcash/zcash/issues/570#issuecomment-296450324 . The latter was the more important issue since I think I already knew that pk_enc wasn’t required for IND-CCA2 when designing Sprout, and was just being cautious/conservative about that. (Including epk as an input, as in DHAES, *is* necessary for IND-CCA2 security, and Sapling still does that.)

The weak-PRF thing was just a nice-to-have that weakened assumptions on the hash; it was not necessary for security, since the stronger assumptions are entirely plausible for BLAKE2b-256.

Thanks Daira for all clarifications. I assume so that for the same reasons the counter variable has been removed from the KDF inputs.

By the way, here (Sec 6.1) there is a proof for IK-CCA of DHIES if you want to have a look .