Numbering of hashes matching IANA

[pawal]

I would very much prefer to have the numbering of the hashes the same as in the IANA registry. If there are some missing, it is easy to add them to the registry.

This would also make it much easier to publish an internet-draft on multihashes, without creating yet another registry.

[jbenet]

@pawal having the same numbers as IANA would be nice, but this wont work for us, as our table is going to grow well beyond that one, include historical hashes that are now broken, and non cryptographic hashes.

[jbenet]

Also, worth mentioning, i have been in contact with people at the IETF and IANA and they do not have a problem with us NOT using that table.

[pawal]

I would like to open up this issue again. If we want multihash to come through IETF, it would be really good to have the same numbering scheme as IANA. Perhaps one could use historical hashes using values over 64.

(I have also done a lot of work within the IETF.)

I can also volunteer to write a proper draft on this.

[Stebalien]

Would that require changing the current multihash constants? If so, this is a non-starter.

[pawal]

Yes.

[Stebalien]

Then, at this point, it would break existing hashes which isn't really an option. We could assign a range for IANA hashes and have duplicates but that's not really an improvement.

[nichtich]

There is no such such as "the IANA registry of hash function" but several lists already exist:

• CCNx Hash Function Types (draft)
• DNSSEC NSEC3 Hash Algorithms (RFC5155)
• DKIM Hash Algorithms (RFC6376)
• EAP Hash Algorithms (RFC4793)
• GSAKMP Nonce Hash Types (RFC 4535)
• Hash Function Textual Names (RFC 8122)
• Hash Algorithms for HTTP Digest Authentication (RFC 7616)
• IKE Hash Algorithm (Value 2) (RFC2409)
• IKEv2 Hash Algorithms (RFC 7427)
• MANET Hash Functions (RFC7182)
• Cert Hash Payload Field Names (RFC 3830, RFC 6309)
• Named Information Hash Algorithm Registry (RFC6920)
• Netnews Cancel-Lock Hash Algorithms (RFC 8315)
• PPSP Peer Protocol Merkle Hash Tree Function Registry (RFC7574)
• PGP Hash Algorithms (RFC 4880)
• RTSP Accept-Credentials Hash Algorithms (RFC 7826)
• syslog-sign Hash Algorithm Values (RFC5848)
• TLS HashAlgorithm (RFC5246, RFC8447)
• VNC URI ID Hash Algorithms (RFC7869)

I'm sure there are more hash function lists out there from other standards bodies as well.

[IS4Code]

I'd add to the list:

• XML Security URIs (RFC 6931)

[melvincarvalho]

There are a number of RFCs that contain hash registries, however AFAIK only RFC6920, Naming Things with Hashes, has the same goal as multihash

I would support any possible alignment

Regarding the 64 IDs, that field seems to be optional

The suite ID field ("ID") can be empty or can have values between 0
   and 63, inclusive.  Because there are only 64 possible values, this
   field is OPTIONAL (leaving it empty if omitted).  Where the binary
   format is not expected to be used for a given hash algorithm, this
   field SHOULD be omitted.

https://tools.ietf.org/html/rfc6920

[nichtich]

There should at least be a mapping between multihash codes and the Named Information Hash Algorithm Registry. Just add a column at https://www.iana.org/assignments/named-information/named-information.xhtml?

[pawal]

@nichtich Section 9.4 and 9.5 of RFC6290 defines the registry, so it may be quite hard to add another column unless you write an RFC that extends that registry and pushes that through in a standards track (working group).

[nichtich]

@nichtich Section 9.4 and 9.5 of RFC6290 defines the registry, so it may be quite hard to add another column unless you write an RFC that extends that registry and pushes that through in a standards track (working group).

Sorry for confusion. I meant to enrich https://github.com/multiformats/multicodec/blob/master/table.csv instead. In addition to IANA ids, Wikidata ids are helpful to get corresponding Wikipedia articles.