Hash algorithm agility for proofs and nodes

[haydentherapper]

Given we don't have a spec yet for tiles, I wanted to ask if there's interest in removing any assumptions that SHA-256 is used for root, node, or leaf hashing or inclusion or consistency proofs. This could apply for sunlight or any log deployments, though I'm thinking more about deployments other than sunlight/CT.

[FiloSottile]

I haven't seen any deployment interest for other hashes, have you? RFC 6962 is SHA-256 only.

The security of SHA-256 is not in doubt, and its performance is AFAIK not a bottleneck in any setting.

This is another ecosystem-wide dimension in the support matrix: if we add a hash we need all witnesses to support it, or some logs will work only with some witnesses. (As opposed to what you put in the leaves, which is completely up to the log.)

[FiloSottile]

Actually, I had a brief conversation at RWC about using zkproof-friendly algebraic hashes like Poseidon. That might be worth it, but 1) Poseidon is not a fixed specification, so we'd need that first and 2) it's a lot of complexity and risk that we should take only if there is a very compelling zero-knowledge proof application that would use it, maybe even a prototype.

Generally, missing compelling reasons to add a parameter, my position always starts at #63 (comment).

[haydentherapper]

I believe there's one internally within Google using SHA-512. No public logs from what I've seen. Like the RSA question, I'm coming from the perspective of early alignment and agility rather than having to add something later down the line, as it will be significant work for the ecosystem to move off SHA-256 once it's hardcoded. I would recommend we explicitly state SHA-256 in the spec for tile layouts if we do have no plans to support other hashes.

If what you want to put content into the leaves will use >SHA-256, let's say for an artifact hash, then it seems strange to have the tree use SHA-256, as that becomes the theoretical cryptographic bottleneck. Not a major issue, just a little awkward.

[FiloSottile]

There is no security concern for SHA-256, and it has at least 128 bits of security, including against collisions. This hasn't been a problem in the ten years since RFC 6962.

There is real interoperability and complexity cost in engineering agility into something, and the benefits here don't seem compelling. I think my thoughts from #63 (comment) apply here, too.