Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: