Ensure Spec mitigates Double Spending by Colliding InternalH

[defuse]

I think I found an attack that would let an attacker create as much money as they want for themselves at the cost of finding 128-bit hash collisions.

Background: A coin is a tuple (a_pk, v, ρ, r). The coin commitment CoinCommitment((a_pk, v, ρ, r)) is computed as:

InternalH = Leading128(CRH(a_pk || ρ))
k = CRH(r || InternalH)
cm = CRH(v || k)

The truncation of InternalH is done to make the commitment statistically-hiding, i.e no matter how much computational resources I have, I can't find out what v or a_pk are.

Attack: Because InternalH is only 128 bits, in 2^64 operations I can find some ρ != ρ' such that:

Leading128(CRH(a_pk || ρ)) = Leading128(CRH(a_pk || ρ'))

And therefore:

CoinCommitment((a_pk, v, ρ, r)) = CoinCommitment((a_pk, v, ρ', r))

To carry out a double-spend attack I first acquire some real Zcash (e.g. by buying it with USD), and then double spend it to myself as follows. Ignoring the faerie gold fix, I create a new coin for myself, but as I do so I make sure to find a collision (a_pk, v, ρ, r) and (a_pk, v, ρ', r) where ρ != ρ'. By completeness of the protocol, I'll be able to spend the (a_pk, v, ρ, r) coin, and so that's what I do. This will reveal the serial number PRF^sn_ask(ρ). After that first spend has made it on to the ledger, as far as I can see, nothing prevents me from spending that coin again, using ρ', because:

• I can still give a path from the root to CoinCommitment((a_pk, v, ρ', r)), namely the same path as I gave in the first spend (and because of the zero-knowledge property nobody will know the path is the same).
• With high probability PRF^sn_ask(ρ') is not equal to PRF^sn_ask(ρ), and I can obviously still prove I computed PRF^sn_ask(ρ') correctly inside the pour.
• I can still satisfy spend authority (I know a_sk for the a_pk I used).
• I have to use the same r (old) for both spends (otherwise the commitments won't collide), but again because of the zero-knowledge property I don't think anyone (except for me, the holder of a_sk) can tell it's been reused.

After the faerie gold fix, I'm forced to find colliding ρ by altering h_sig, and I'm forced to commit to either ρ or ρ' because h_sig gets published. This doesn't prevent the attack, since when I go to spend for the second time it is not going to be noticed that ρ' doesn't match the old h_sig, at least not according to the current protocol.

Fix: Maybe CoinCommitment needs to be collision-resistant? Or maybe we should re-use h_sig as a commitment to ρ and check it when I try to spend with ρ?

[defuse]

In other words, CoinCommitment() isn't computationally binding, and the above attack is a consequence of that.

[daira]

Yes, this appears to work. Excellent catch!

After the faerie gold fix, I'm forced to find colliding ρ by altering h_Sig

Or φ.

[ebfull]

Awesome find @defuse!

I was also suspicious of the security of that function but didn't realize there was an attack at the time.

[daira]

In the proof of Balance in section D.3, the attack violates either Condition I, if the double-spend is within a single Pour (i.e. the doubled coin is spent in both inputs), or Condition II, if the double-spend occurs across Pours.

For Condition I, the failure is here:

(i) If cm^old₁ = cm^old₂, then the fact that sn^old₁ = sn^old implies that the witness a contains two distinct openings of cm^old₁ (the first opening contains (a^old_sk,1, ρ^old₁), while the second opening contains (a^old_sk,2, ρ^old₂)). This violates the binding property of the commitment scheme COMM.

For Condition II, the failure is here:

However (as argued already above), if both transactions spend cm but produce different serial numbers, then the corresponding witnesses a, a contain different openings of cm. This contradicts the binding property of the commitment scheme COMM.

(Note that the proofs should really be distinguishing between COMM^r and COMM^s since they are different constructions, but we'll let that pass for now.)

Let's look at whether the above arguments actually follow from the definition of binding for a commitment scheme (spoiler: they do). Note that the Zerocash paper doesn't define binding at all; it only says:

Statistically-hiding commitments. We use a commitment scheme COMM where the binding property holds computationally, while the hiding property holds statistically. It is denoted {COMM_x : {0, 1}^∗ → {0, 1}^O(λ)}_x where x denotes the commitment trapdoor. Namely, to reveal a commitment cm to a value z, it suffices to provide z and the trapdoor x; then one can check that cm = COMM_x(z).

Finding a precisely-stated definition of computational binding security was suprisingly time-consuming. Wikipedia gives a silly definition that I won't confuse you with. (Exercise: beside being asymptotic, what else is wrong with it?) Definition 24.1 in http://www.zurich.ibm.com/~cca/sft13/smart08chaps2426.pdf will suffice:

A commitment scheme is said to be [computationally] binding if no [computationally bounded] adversary can win the following game.
• The adversary outputs a value c, plus values x and r which produce this commitment.
• The adversary must then output a value x′ ≠ x and a value r′ such that C(x, r) = C(x′, r′).

(r is the randomness, x is the committed value.) This indeed would be sufficient for the arguments in the security proof. COMM^r would have this binding property if Leading128 ∘ CRH were collision-resistant, but obviously, that doesn't hold at a 128-bit security level. (Actually, we need that the composition of COMM^r and COMM^s is binding on all of the inputs, i.e. a_pk, ρ, and v, but the problem in this attack is with COMM^r.)

Note that collision resistance of Leading128 ∘ CRH was not explicitly assumed in the construction of COMM in section 5.1. (Even if we didn't need that, we would still need Leading253 ∘ CRH to be collision-resistant, which is also not explicitly assumed, because of the truncation of h_Sig and ρ.)

[daira]

So let's see: we need to commit to a_pk, ρ, and v, which are a total of 256+256+64 = 576 bits. It's questionable whether we actually need the statistical hiding property, or whether we can get it (note that the scheme must also be noninteractive, which rules out some constructions in the literature) at reasonable circuit cost. Note that we don't have "everlasting anonymity" anyway because of the encryption. If we only need computational hiding and computational binding, then we could just do:

InternalH = CRH(a_pk || ρ)
cm = CRH(v || r || InternalH) where r is 192 bits

[daira]

Another option is to use the full SHA-256 hash:

cm = SHA-256(a_pk || v || ρ || r)

(Length extension attacks aren't a problem here.) This also requires two compression function evaluations but leaves more scope for possible future changes, because we're effectively saving 256 bits from the input to the second compression function (minus the minimum one byte of padding) by putting it in the chaining variable.

Edit: swap order of v and ρ to be the same order as in the definition of a coin and as encoded in a coin plaintext.

[defuse]

Using two hashes or full SHA256 would be nicer because we could have better domain separation between things, and not have to worry as much about things like this: #500 (comment)