Flow is Still Flawed
Dapper Labs has responded to our previous post about flaws in their new Flow protocol. They graciously thanked us for our critique and offered some kind words, both of which are appreciated. But unfortunately the changes to their design don’t fix all of the problems with Flow.
To review, we pointed out that their new “SPoCK” (Specialized Proof of Confidential Knowledge) cryptographic primitive didn’t have the properties they claimed — not truly proving possession of the “confidential knowledge” and therefore not accomplishing what the Flow protocol needed. We also pointed out that their protocol for verifying claimed results of computation had bad equilibria in which everybody lied and an incorrect result was accepted.
As we’ll explain in more detail, although their new post makes some improvements, the two underlying problems — weaknesses in SPoCKs and bad equilibria — still remain.
SPoCKs Still Not Strong Enough
A SPoCK is supposed to demonstrate that some party Alice has knowledge of a secret value ζ. In the original construction, ζ would be used to generate a key pair (sk, pk), and then the SPoCK (pk, sign_sk(ID)), where ID is Alice’s public identifier, would purportedly prove Alice’s knowledge of ζ. We pointed out that this process didn’t depend on any secret knowledge of Alice’s, so anybody could make a SPoCK in Alice’s name. It followed that a SPoCK did not prove Alice’s knowledge of anything.
Dapper Labs published this purported fix:
The fix is straightforward: Instead of using the SPoCK key-pair to sign Alice’s public ID, we use it to sign a value that only Alice could have: another signature (this one generated with the standard key-pair Alice uses to prove her identity). The value she signs isn’t important, but to prevent replay attacks, it should be derived from some value publicly associated with the current challenge which is highly unlikely to repeat for other challenges, and which is highly unlikely to be signed by any potential prover for any other purpose.
The SPoCK would now be (pk, sign_sk(sign_skA(chal, ID)), where skA is Alice’s secret key and chal is a value publicly associated with the current challenge. (Note that in these protocols, sign(x) implicitly conveys not only a bare signature, but also the value x being signed. Otherwise the recipient of a signature couldn’t verify it.)
The modified SPoCK construction still fails. The problem is that the SPoCK is malleable. Given Alice’s SPoCK for one value ζ, anyone can compute Alice’s valid SPoCK for any other value. If Alice has made the SPoCK above, and Bob has seen it, then Bob can copy the sign_skA(chal,ID) part and Bob can compute (P, sign_S(sign_skA(chal,ID)) where (P,S) is a different key-pair not derived from the true ζ. This would be a “proof” that Alice knows some value (other than ζ) which she does not in fact know. This is possible because the information that Alice signs is independent of ζ, even though the SPoCK is supposed to show that Alice knows ζ.
So, it’s back to the drawing board. We were tempted to try to fix the new SPoCK construction by including pk in the information Alice signs or by wrapping another Alice-signature around the whole thing, but those constructions also both fail to prove Alice’s knowledge of ζ; we’ll spare you a detailed explanation of why.
Rather than going further down the road of “propose, break, patch, repeat” we would urge Dapper Labs to carefully state the formal property their construction provides, then provide at least a semi-formal proof that the construction has that property. No need to go full CRYPTO-paper formal, but at this point a proven-correct-by-construction approach seems to be the only viable way forward.
Flows’s Verification Still Has Incentive Problems
Our other critique of Flow was that its protocol doesn’t solve the Verifier’s Dilemma because it doesn’t prevent the failure scenario explained in our previous post. We’re grateful to Dapper Labs for clarifying their argument. We think their system still suffers, like many others do, from bad equilibria where false claims are occasionally made and lazy verifiers go along with claims rather than checking them. We’ll explain why in a subsequent post.
