Content
@
https://warpcast.com/~/channel/ipfs
0 reply
0 recast
0 reaction
Steve
@stevedylandev.eth
A few weeks ago when the Safe frontend was compromised, there were a lot of conversations about how IPFS could have solved the issue, but also some potential failure points. One of those was IPFS Gateways. These are hosted IPFS nodes that retrieve content and return it to the person using the gateway, and a weakness is the possibility of someone compromising the gateway and returning ContentXYZ instead of the requested ContentABC. This made me wonder: what if we could prove the CID? I'm still in the early exploration phases of this project, but the idea is to run a ZK proof of the CID with the content that is retrieved from IPFS to generate a proof that can be verified by the client. Currently using SP1 by Succinct and it seems to be working š Would love any comments or ideas on this! Repo linked below: https://github.com/stevedylandev/cid_proof
4 replies
1 recast
10 reactions
Julie B.
@bbjubjub.eth
So the file contents are a private input? (I'm rusty on SP1) And the CID is a public output?
1 reply
0 recast
1 reaction
Steve
@stevedylandev.eth
Yup exactly! The file contents (the actual data) are provided as a private input to the proof generation. This means the content itself doesn't need to be revealed to verify the proof. The CID components (the `cid_bytes`, `cid_bytes_remainder`, and `cid_length`) are the public outputs that are committed to within the proof.
1 reply
0 recast
0 reaction
Julie B.
@bbjubjub.eth
So what guarantees do such proofs provide if the contents aren't committed to in the proof? Can I serve contentXYZ next to a proof for contentABC?
1 reply
0 recast
1 reaction
Steve
@stevedylandev.eth
That's kind of the beauty of ZK proofs. The proof system guarantees that the prover knows content that hashes to the specific CID committed in the public output. While the file contents are private inputs, they're cryptographically bound to the public CID output through the ZK proof. To prevent the attack you described (serving wrong content with a valid proof): 1. The proof verifies the prover knows content matching the CID 2. The verifier must also hash the received content to confirm it matches the CID The security comes from combining proof verification with a simple content hash check. The system prevents the gateway from creating valid proofs for modified content due to the collision-resistance of cryptographic hash functions.
1 reply
0 recast
0 reaction
