Hacker News Reader

Comment by waynenilsen | Hacker News Reader

This article made a false statement

> the gateway is in full control and can inspect and tamper with the data as much as it likes. And there is no way for the client to know or detect if it is happening.

Regarding data tampering;

IPFS uses content based addressing, the point is that the client _can_ know by computing a message digest of the incoming data. The verification is fast and cheap.

View on HN

As others have said, it's not as straightforward because the CID contains a hash of the data's encoding which is not the same as the data itself (files are chunked into pieces to facilitate incremental verifiability and better caching, the encoding supports directories, etc.).

Here is IPFS's master issue for "verifiable gateway responses", which summarizes the technical challenges and progress: https://github.com/ipfs/in-web-browsers/issues/128.

The hash you have is computed from the hash of the content and other data. You would need to send that additional data out-of-band to allow the client to compute the overall hash and verify it. (Not to mention with urls like ipfs://<hash>/some/path you only have the hash of some arbitrary parent node, so there's even more additional data necessary to be able to verify that the content at that path under the hash you have is valid).

You do not need to send the additional data out of band unless you are claiming that sha-2 (the hash function used in ipfs) is vulnerable to second preimage attacks.

It's not possible to verify a file downloaded from IPFS using only its CID, because an IPFS CID does not contain a checksum of the file content. It contains the checksum of a meta-file, which contains the hashes of further meta-files.

For example, debian-10.7.0-amd64-netinst.iso has SHA256 checksum b317d87b0a3d5b568f48a92dcabfc4bc51fe58d9f67ca13b013f1b8329d1306d. Here are two example CIDs generated from that file:

https://cid.ipfs.tech/#bafybeihjy54iyvheotna2aeqmzhqnro6yot4...

https://cid.ipfs.tech/#bafybeihfqpypuhmtyzazrj3g4b4f4nqk2ziy...

Notice that neither one contains the original checksum.

> The verification is fast and cheap.

And yet the most widely used IPFS client, Brave, does not implement this.

The blog post is technically wrong, but I think it's worth accounting for the general state of the ecosystem in these decisions, and in whether to include IPFS in cURL, and it sounds like the general state of the ecosystem is not up to the standards that cURL should reasonably expect from a protocol asking for inclusion.

Brave uses its own local gateway running go-ipfs. go-ipfs verifies the content, so Brave does not have to.

You only have to verify the content yourself if it is not being verified by someone you trust (i.e. a local gateway that you're running yourself).

That's not what their documentation says. It says that it uses a public gateway, and prompts the user asking if they would like to use a local gateway, at which point it will download go-ipfs and run that. That's a fairly smooth UX to get a local gateway running, but I wouldn't bet money on it being used by the majority. Most people take the path of least resistance, and it's up to projects like Brave or cURL to ensure that the path is safe, which in this case it is not for Brave.

Verification would require more data than CID itself provides (ipld document layout, chunking algorithm, max chunk sizes...).

See https://github.com/multiformats/cid/issues/22

Not providing verification would seem like a nearly fatal flaw would it not? If one cannot pass around IPFS urls and ensure that the content returned is the same for all users, it would make a great way to MiTM a target.

Reply on news.ycombinator.com