4 ms·
I wonder if storing the hashing parameters next to the hash is the right approach to take for systems. Your system isn't going to support all hashes (adds a lot
by y7 10y ago
I wonder if storing the hashing parameters next to the hash is the right approach to take for systems. Your system isn't going to support all hashes (adds a lot of library bloat, you don't want to support weak hashes), so you'll probably want one specific algorithm/parameter set, with room for upgrades in case weaknesses get discovered (not likely to occur often). A single byte/varint, starting at 0 and incrementing for every new parameter set sounds reasonable. A downside would be interoperability, but if that's your main concern then perhaps a human-readable string representation of the hash algorithm/parameters would be preferable.
What are the benefits of using Multihash?
- Kubuxu 10y agoYou don't have to support hashing with all hash functions. In theory you could accept just few (and thus have their implementations) and error out in case of one that is not supported comes through.
- Kubuxu 10y agoYou don't have to support hashing with all hash functions. In theory you could accept just few (and thus have their implementations) and error out in case of one that is not supported comes through.
- _prometheus 10y agoTruncations happen in many sizes. The combinations here are not helpful: N functions * M commonly chosen sizes. Simple assumptions: 20 functions * 10 sizes = 200 codes. already not good. You can print a human-readable version of multihash as: sha2-256-20B-<hex> Using the same values of the table. But again, it is preferable that it travels in-band with the values, as otherwise it will likely get chopped up and placed into out of band context.