On the security of Sprout/Sapling in-band encryption

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.

1 Like

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.

2 Likes

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 :smiley:

1 Like

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.

4 Likes

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 :smiley:.

2 Likes