ipfs

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

DX Engineer | Head of Developer Relations at /pinata | Building orbiter.host | stevedylan.dev/links

So the file contents are a private input?   (I'm rusty on SP1) And the CID is a public output?

Auditoooor at ChainSecurity
—
EPFL Cybersec MSc.
—
CTF player w/ 0rganizers
—
Hacker & Cypherpunk
—
🌸

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?

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.