Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's discussed in the article that a different issue is tooling assuming the hash length won't change. That's an issue that came up with the recent SHA1 issues and git. Lots of git tooling assumes the hash is 160-bits. For example, a website displaying git history might be formatted for the hash field to be exactly 320 pixels wide, enough to fit a hex encoded 160-bit string in an 8px monospace font. If suddenly the hash needs to be 256-bits, the site needs to be redesigned.

Multihash seems to argue that by using an TLV encoding on the hash, that will make it clear that the hash length is dynamic, so tooling will design with that in mind.

Simply assuming that you can rev the version of your protocol in the future doesn't communicate to outside developers that, for example, hash lengths in your protocol could change in the future.

I'm not sure I agree with Multihash's argument, though, and on average I agree with your methodology in systems I design. Keeping the crypto fixed per version makes implementations and tooling simpler and thus easier to debug/less chance of [INSERT WORD]Bleed. That outweighs the supposed future proofing of things like multihash, in my mind, and I also feel a lot of designers won't take the hint even when presented with a TLV encoded hash.



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

Search: