Hacker News Reader

Comment by cpuguy83 | Hacker News Reader

sha256 has been around a long time and is highly compatible.

blake3 support has been proposed both in the OCI spec and in the runtimes, which at least for runtimes I expect to happen soon.

I tend to think gzip is the bigger problem, though.

View on HN

> sha256 has been around a long time and is highly compatible.

Sure, and one can construct a perfectly nice tree hash from SHA256. (AWS Glacier did this, but their construction should not be emulated.)

But then every single client needs to support this. sha256 support is already ubiquitous.

Every single client already had to implement enough of the OCI distribution spec to be able to parse and download OCI images. Implementing a more appropriate hash, which could be done using SHA-256 as a primitive, would have been a rather small complication. A better compression algorithm (zstd?) is far more complex.

I don't think we can compare reading json to writing a bespoke, secure hashing algorithm across a broad set of languages.

Reading JSON that contains a sort of hash tree already. It’s a simple format that contains a mess of hashes that need verifying over certain files.

Adding a rule that you hash the files in question in, say, 1 MiB chunks and hash the resulting hashes (and maybe that’s it, or maybe you add another level) is maybe 10 lines of code in any high level language.

Note that secure tree hashing requires a distinguisher between the leaves and the parents (to avoid collisions) and ideally another distinguisher between the root and everything else (to avoid extensions). Surprisingly few bespoke tree hashes in the wild get this right.

This is why I said that Glacier’s hash should not be emulated.

FWIW, using a (root hash, data length) pair hides many sins, although I haven’t formally proven this. And I don’t think that extension attacks are very relevant to the OCI use case.

Reply on news.ycombinator.com