├── .gitignore
├── .htaccess
├── CODEOWNERS
├── CONTRIBUTING.md
├── LICENSE.md
├── README.md
├── gen-identifier-registry
├── index.xml
└── rfc2629.xsl


/.gitignore:
--------------------------------------------------------------------------------
1 | *.sw[nop]
2 | *~
3 | .project
4 | .settings
5 | TAGS
6 | 


--------------------------------------------------------------------------------
/.htaccess:
--------------------------------------------------------------------------------
1 | DirectoryIndex index.xml
2 | 


--------------------------------------------------------------------------------
/CODEOWNERS:
--------------------------------------------------------------------------------
1 | # These owners will be the default owners for everything in
2 | # the repo. Unless a later match takes precedence,
3 | # they will be requested for review when someone opens a 
4 | # pull request.
5 | *       @jbenet @msporny @gannan08 @rhiaro
6 | 
7 | # See CODEOWNERS syntax here: https://help.github.com/articles/about-codeowners/#codeowners-syntax
8 | 


--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
 1 | # W3C Credentials Community Group
 2 | 
 3 | Contributions to this repository are intended to become part of
 4 | Recommendation-track documents governed by the
 5 | [W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy-20040205/) and
 6 | [Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software).
 7 | To make substantive contributions to specifications, you must either participate
 8 | in the relevant W3C Working Group or make a non-member patent licensing commitment.
 9 | 
10 | If you are not the sole contributor to a contribution (pull request), please
11 | identify all contributors in the pull request comment.
12 | 
13 | To add a contributor (other than yourself, that's automatic), mark them one
14 | per line as follows:
15 | 
16 | ```
17 | +@github_username
18 | ```
19 | 
20 | If you added a contributor by mistake, you can remove them in a comment with:
21 | 
22 | ```
23 | -@github_username
24 | ```
25 | 
26 | If you are making a pull request on behalf of someone else but you had no
27 | part in designing the feature, you can remove yourself with the above syntax.
28 | 


--------------------------------------------------------------------------------
/LICENSE.md:
--------------------------------------------------------------------------------
1 | All Reports in this Repository are licensed by Contributors under the [W3C Software and Document
2 | License](https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document).
3 | 
4 | Contributions to Specifications are made under the
5 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/).
6 | 
7 | Contributions to Software, including sample implementations, are under the
8 | [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).
9 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | ## The Multihash Data Format
 2 | 
 3 | This specification describes a data model for expressing the output of
 4 | cryptographic hash functions.
 5 | 
 6 | Cryptographic hash functions often have multiple output sizes and encodings.
 7 | This variability makes it difficult for applications to examine a series of
 8 | bytes and determine which hash function produced them. Multihash is a universal
 9 | data format for encoding outputs from hash functions. It is useful to write
10 | applications that can simultaneously support different hash function outputs as
11 | well as upgrade their use of hashes over time; Multihash is intended to
12 | address these needs.
13 | 
14 | You can view an HTML version of the specification here:
15 | 
16 | [https://w3c-ccg.github.io/multihash/](https://w3c-ccg.github.io/multihash/)
17 | 
18 | We encourage contributions meeting the [Contribution
19 | Guidelines](CONTRIBUTING.md).  While we prefer the creation of issues
20 | and Pull Requests in the GitHub repository, discussions often occur
21 | on the
22 | [public-credentials](http://lists.w3.org/Archives/Public/public-credentials/)
23 | mailing list as well.
24 | 
25 | ### Other useful links
26 | * [Multiformats Website](https://multiformats.io/)
27 | * [Multihash Website](https://multiformats.io/multihash/)
28 | * [Public group email archive](https://lists.w3.org/Archives/Public/public-credentials/)
29 | 


--------------------------------------------------------------------------------
/gen-identifier-registry:
--------------------------------------------------------------------------------
 1 | #!/usr/bin/env python3
 2 | #
 3 | # Script to generate the multihash identifier registry from the CSV file
 4 | import codecs
 5 | import csv
 6 | import urllib.request
 7 | 
 8 | url = 'https://raw.githubusercontent.com/multiformats/multicodec/master/table.csv'
 9 | stream = urllib.request.urlopen(url)
10 | csvdata = csv.reader(codecs.iterdecode(stream, 'utf-8'))
11 | 
12 | print("""
13 |       <texttable anchor="mh-registry-table" title="Multihash Identifier Registry">
14 |         <ttcol align="center">Name</ttcol>
15 |         <ttcol align="center">Identifier</ttcol>
16 |         <ttcol align="center">Status</ttcol>
17 |         <ttcol align="center">Specification</ttcol>
18 | """)
19 | 
20 | for line in csvdata:
21 |     if line[1].strip() != 'multihash':
22 |         continue
23 | 
24 |     if line[3].strip() != 'permanent':
25 |         continue
26 | 
27 |     codec = line[0].strip()
28 |     identifier = line[2].strip()
29 |     status = 'active'
30 |     spec = 'Unknown'
31 | 
32 |     if(codec.startswith('blake2')):
33 |         spec = '<xref target="RFC7693">RFC 7693</xref>'
34 |     elif(codec.startswith('sha1')):
35 |         spec = '<xref target="RFC6234">RFC 6234</xref>'
36 |     elif(codec.startswith('sha2')):
37 |         spec = '<xref target="RFC6234">RFC 6234</xref>'
38 |     elif(codec.startswith('sha3')):
39 |         spec = '<xref target="FIPS202">FIPS 202</xref>'
40 |     elif(codec.startswith('poseidon')):
41 |         spec = '<xref target="POSEIDON">POSEIDON</xref>'
42 |     elif(codec.startswith('md4')):
43 |         status = 'deprecated'
44 |         spec = '<xref target="RFC6150">RFC 6150</xref>'
45 |     elif(codec.startswith('md5')):
46 |         status = 'deprecated'
47 |         spec = '<xref target="RFC6151">RFC 6151</xref>'
48 | 
49 |     print(f'        <c>{codec}</c><c>{identifier}</c><c>{status}</c><c>{spec}</c>')
50 | 
51 | print('      </texttable>')
52 | 


--------------------------------------------------------------------------------
/index.xml:
--------------------------------------------------------------------------------
  1 | <?xml version='1.0' encoding='utf-8'?>
  2 | <?xml-stylesheet type="text/xsl" href="rfc2629.xsl" ?>
  3 | <?rfc compact="yes" ?>
  4 | <?rfc subcompact="no" ?>
  5 | <?rfc toc="yes" ?>
  6 | <?rfc sortrefs="yes" ?>
  7 | <?rfc symrefs="yes" ?>
  8 | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
  9 |   ipr="trust200902" submissionType="IETF"
 10 |   docName="draft-multiformats-multihash-07"
 11 |   tocInclude="true" sortRefs="true" symRefs="true" version="2">
 12 | 
 13 | <front>
 14 |   <title>The Multihash Data Format</title>
 15 |   <seriesInfo name="Internet-Draft" value="draft-multiformats-multihash-07"/>
 16 | 
 17 |   <author initials="J." surname="Benet" fullname="Juan Benet">
 18 |     <organization>Protocol Labs</organization>
 19 |     <address>
 20 |       <postal>
 21 |         <street>548 Market Street, #51207</street>
 22 |         <city>San Francisco</city>
 23 |         <region>CA</region>
 24 |         <code>94104</code>
 25 |         <country>US</country>
 26 |       </postal>
 27 |       <phone>+1 619 957 7606</phone>
 28 |       <email>juan@protocol.ai</email>
 29 |       <uri>http://juan.benet.ai/</uri>
 30 |     </address>
 31 |   </author>
 32 | 
 33 |   <author initials="M." surname="Sporny" fullname="Manu Sporny">
 34 |     <organization>Digital Bazaar</organization>
 35 |     <address>
 36 |       <postal>
 37 |         <street>203 Roanoke Street W.</street>
 38 |         <city>Blacksburg</city>
 39 |         <region>VA</region>
 40 |         <code>24060</code>
 41 |         <country>US</country>
 42 |       </postal>
 43 |       <phone>+1 540 961 4469</phone>
 44 |       <email>msporny@digitalbazaar.com</email>
 45 |       <uri>http://manu.sporny.org/</uri>
 46 |     </address>
 47 |   </author>
 48 | 
 49 |   <date month="August" day="20" year="2023" />
 50 |   <area>Security</area>
 51 |   <workgroup />
 52 |   <keyword>digest algorithm</keyword>
 53 |   <keyword>digital signature</keyword>
 54 |   <keyword>PKI</keyword>
 55 |   <keyword>SHA</keyword>
 56 |   <keyword>BLAKE</keyword>
 57 |   <keyword>poseidon</keyword>
 58 | 
 59 |   <abstract>
 60 |     <t>
 61 | Cryptographic hash functions often have multiple output sizes and encodings.
 62 | This variability makes it difficult for applications to examine a series of
 63 | bytes and determine which hash function produced them. Multihash is a universal
 64 | data format for encoding outputs from hash functions. It is useful to write
 65 | applications that can simultaneously support different hash function outputs as
 66 | well as upgrade their use of hashes over time; Multihash is intended to
 67 | address these needs.
 68 |     </t>
 69 |   </abstract>
 70 | 
 71 |   <note title="Feedback">
 72 |     <t>
 73 | This specification is a joint work product of
 74 | <eref target="https://protocol.ai/">Protocol Labs</eref> and the
 75 | <eref target="https://w3c-ccg.github.io/">W3C Credentials Community Group</eref>.
 76 | Feedback related to this specification should logged in the
 77 | <eref target="https://github.com/w3c-ccg/multihash/issues">issue tracker</eref>
 78 | or be sent to
 79 | <eref target="mailto:public-credentials@w3.org">public-credentials@w3.org</eref>.
 80 |     </t>
 81 |   </note>
 82 | </front>
 83 | <middle>
 84 |   <section anchor="intro" title="Introduction">
 85 |     <t>
 86 | Multihash is particularly important in systems which depend on
 87 | cryptographically secure hash functions. Attacks may break the cryptographic
 88 | properties of secure hash functions. These cryptographic breaks are
 89 | particularly painful in large tool ecosystems, where tools may have made
 90 | assumptions about hash values, such as function and digest size. Upgrading
 91 | becomes a nightmare, as all tools which make those assumptions would have
 92 | to be upgraded to use the new hash function and new hash digest length.
 93 | Tools may face serious interoperability problems or error-prone special casing.
 94 |     </t>
 95 |     <t>
 96 | How many programs out there assume a git hash is a SHA-1 hash?
 97 |     </t>
 98 |     <t>
 99 | How many scripts assume the hash value digest is exactly 160 bits?
100 |     </t>
101 |     <t>
102 | How many tools will break when these values change?
103 |     </t>
104 |     <t>
105 | How many programs will fail silently when these values change?
106 |     </t>
107 |     <t>
108 | This is precisely why Multihash was created. It was designed for
109 | seamlessly upgrading systems that depend on cryptographic hashes.
110 |     </t>
111 |     <t>
112 | When using Multihash, a system warns the consumers of its hash values that
113 | these may have to be upgraded in case of a break. Even though the system
114 | may still only use a single hash function at a time, the use of multihash
115 | makes it clear to applications that hash values may use different hash
116 | functions or be longer in the future. Tooling, applications, and scripts
117 | can avoid making assumptions about the length, and read it from the
118 | multihash value instead. This way, the vast majority of tooling - which
119 | may not do any checking of hashes - would not have to be upgraded at all.
120 | This vastly simplifies the upgrade process, avoiding the waste of hundreds
121 | or thousands of software engineering hours, deep frustrations, and high
122 | blood pressure.
123 |     </t>
124 |   </section>
125 |   <section anchor="components" title="The Multihash Fields">
126 |     <t>
127 | A multihash follows the TLV (type-length-value) pattern and consists of
128 | several fields composed of a combination of unsigned variable length
129 | integers and byte information.
130 |     </t>
131 |     <section anchor="core-data-types" title="Multihash Core Data Types">
132 |       <t>
133 | The following section details the core data types used by the Multihash
134 | data format.
135 |     </t>
136 |       <section anchor="cdt-uvi" title="unsigned variable integer">
137 |         <t>
138 | A data type that enables one to express an unsigned integer of variable length.
139 | The format uses the Little Endian Base 128 (LEB128) encoding that is defined in
140 | Appendix C of the
141 | <xref target="DWARF">DWARF Debugging Information Format</xref> standard,
142 | initially released in 1993.
143 |         </t>
144 |         <t>
145 | As suggested by the name, this variable length encoding is only capable of
146 | representing unsigned integers.  Further, while there is no theoretical maximum
147 | integer value that can be represented by the format, implementations MUST NOT
148 | encode more than nine (9) bytes giving a practical limit of integers in a range
149 | between 0 and 2^63 - 1.
150 |         </t>
151 |         <t>
152 | When encoding an unsigned variable integer, the unsigned integer is serialized
153 | seven bits at a time, starting with the least significant bits. The most
154 | significant bit in each output byte indicates if there is a
155 | continuation byte. It is not possible to express a signed integer with this
156 | data type.
157 |         </t>
158 |         <texttable anchor="mh-uvi-examples" title="Examples of Unsigned Variable Integers">
159 |           <ttcol align="center">Value</ttcol>
160 |           <ttcol align="right">Encoding (bits)</ttcol>
161 |           <ttcol align="right">hexadecimal notation</ttcol>
162 |           <c>1</c>
163 |           <c>00000001</c>
164 |           <c>0x01</c>
165 |           <c>127</c>
166 |           <c>01111111</c>
167 |           <c>0x7F</c>
168 |           <c>128</c>
169 |           <c>10000000 00000001</c>
170 |           <c>0x8001</c>
171 |           <c>255</c>
172 |           <c>11111111 00000001</c>
173 |           <c>0xFF01</c>
174 |           <c>300</c>
175 |           <c>10101100 00000010</c>
176 |           <c>0xAC02</c>
177 |           <c>16384</c>
178 |           <c>10000000 10000000 00000001</c>
179 |           <c>0x808001</c>
180 |         </texttable>
181 |         <t>
182 | Implementations MUST restrict the size of the varint to a max of nine bytes
183 | (63 bits). In order to avoid memory attacks on the encoding, the
184 | aforementioned practical maximum length of nine bytes is used. There is
185 | no theoretical limit, and future specs can grow this number if it is truly
186 | necessary to have code or length values larger than 2^31.
187 |         </t>
188 |       </section>
189 |     </section>
190 |     <section anchor="fields" title="Multihash Fields">
191 |       <t>
192 | A multihash follows the TLV (type-length-value) pattern.
193 |         </t>
194 |       <section anchor="hfi" title="Hash Function Identifier">
195 |         <t>
196 |           The hash function identifier is an
197 |           <eref target="#cdt-uvi">unsigned variable integer</eref>
198 |           identifying the hash
199 | function. The possible values for this field are provided in
200 |           <eref target="#mh-registry">The Multihash Identifier Registry</eref>.
201 |         </t>
202 |       </section>
203 |       <section anchor="dl" title="Digest Length">
204 |         <t>
205 |           The digest length is an
206 |           <eref target="#cdt-uvi">unsigned variable integer</eref>
207 |           counting the length of the digest in bytes.
208 |         </t>
209 |       </section>
210 |       <section anchor="dv" title="Digest Value">
211 |         <t>
212 | The digest value is the hash function digest with a length of exactly what is
213 | specified in the digest length, which is specified in bytes.
214 |         </t>
215 |       </section>
216 |     </section>
217 |     <section anchor="mh-example" title="A Multihash Example">
218 |       <t>
219 | 
220 |         For example, the following is an expression of a SHA2-256 hash in hexadecimal
221 | notation (spaces added for readability purposes):
222 |         <figure>
223 |           <artwork>0x12 20 41dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8</artwork>
224 |         </figure>
225 |         The first byte (0x12) specifies the SHA2-256 hash function. The second byte
226 | (0x20) specifies the length of the hash, which is 32 bytes. The rest of the
227 | data specifies the value of the output of the hash function.
228 |       </t>
229 |     </section>
230 |   </section>
231 | </middle>
232 | 
233 | <back>
234 |   <references title="Normative References">
235 |     <reference anchor="DWARF" target="http://dwarfstd.org/doc/Dwarf3.pdf">
236 |       <front>
237 |         <title>DWARF Debugging Information Format, Version 3</title>
238 |         <author fullname="DWARF Debugging Information Format Workgroup" role="editor" surname="DWARF Debugging Information Format Workgroup"/>
239 |         <date month="December" year="2005"/>
240 |         <abstract>
241 |           <t>This document defines the format for the information generated by compilers, assemblers and linkage editors, that is necessary for symbolic, source-level debugging.</t>
242 |         </abstract>
243 |       </front>
244 |     </reference>
245 | 
246 |     <reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6234">
247 |       <front>
248 |         <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
249 |         <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
250 |         <author fullname="T. Hansen" initials="T." surname="Hansen"/>
251 |         <date month="May" year="2011"/>
252 |         <abstract>
253 |           <t>Federal Information Processing Standard, FIPS</t>
254 |         </abstract>
255 |       </front>
256 |       <seriesInfo name="RFC" value="6234"/>
257 |       <seriesInfo name="DOI" value="10.17487/RFC6234"/>
258 |     </reference>
259 | 
260 |     <reference anchor="FIPS202" target="https://doi.org/10.6028/NIST.FIPS.202">
261 |       <front>
262 |         <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
263 |         <author fullname="Information Technology Laboratory, National Institute of Standards and Technology" role="editor" surname="National Institute of Standards and Technology"/>
264 |         <date month="August" year="2015"/>
265 |         <abstract>
266 |           <t>This Standard specifies the Secure Hash Algorithm-3 (SHA-3) family of functions on binary data.</t>
267 |         </abstract>
268 |       </front>
269 |       <seriesInfo name="FIPS" value="202"/>
270 |       <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
271 |     </reference>
272 | 
273 |     <reference anchor="POSEIDON" target="https://eprint.iacr.org/2019/458.pdf">
274 |       <front>
275 |         <title>POSEIDON: A New Hash Function for Zero-Knowledge Proof Systems</title>
276 |         <author fullname="Lorenzo Grassi" role="editor" surname="Grassi" initials="L." />
277 |         <author fullname="Dmitry Khovratovich" surname="Khovratovich" initials="D." />
278 |         <author fullname="Christian Rechberger" surname="Rechberger" initials="C." />
279 |         <author fullname="Arnab Roy" surname="Roy" initials="A." />
280 |         <author fullname="Markus Schofnegger" surname="Schofnegger" initials="M." />
281 |         <date month="November" year="2019"/>
282 |         <abstract>
283 |           <t>A modular framework and concrete instances of cryptographic hash functions which work natively with GF(p) objects. The POSEIDON hash function uses up to 8x fewer constraints per message bit than a Pedersen Hash.</t>
284 |         </abstract>
285 |       </front>
286 |     </reference>
287 | 
288 |     <reference anchor="RFC7693" target="https://www.rfc-editor.org/info/rfc7693">
289 |       <front>
290 |         <title>The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)</title>
291 |         <author fullname="M-J. Saarinen" role="editor" surname="M-J. Saarinen"/>
292 |         <author fullname="J-P. Aumasson" surname="J-P. Aumasson"/>
293 |         <date month="November" year="2015"/>
294 |         <abstract>
295 |           <t>This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community.  BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures.  BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).</t>
296 |         </abstract>
297 |       </front>
298 |       <seriesInfo name="RFC" value="7693"/>
299 |       <seriesInfo name="DOI" value="10.17487/RFC7693"/>
300 |     </reference>
301 |   </references>
302 | 
303 |   <references title="Informative References">
304 |     <reference anchor="RFC6150" target="https://www.rfc-editor.org/info/rfc6150">
305 |       <front>
306 |         <title>MD4 to Historic Status</title>
307 |         <author fullname="S. Turner" initials="S." surname="Turner"/>
308 |         <author fullname="L. Chen" initials="L." surname="Chen"/>
309 |         <date month="March" year="2011"/>
310 |         <abstract>
311 |           <t>This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so.  This document moves RFC 1320 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
312 |         </abstract>
313 |       </front>
314 |       <seriesInfo name="RFC" value="6150"/>
315 |       <seriesInfo name="DOI" value="10.17487/RFC6150"/>
316 |     </reference>
317 |     <reference anchor="RFC6151" target="https://www.rfc-editor.org/info/rfc6151">
318 |       <front>
319 |         <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title>
320 |         <author fullname="S. Turner" initials="S." surname="Turner"/>
321 |         <author fullname="L. Chen" initials="L." surname="Chen"/>
322 |         <date month="March" year="2011"/>
323 |         <abstract>
324 |           <t>This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so.  This document moves RFC 1320 to Historic status.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
325 |         </abstract>
326 |       </front>
327 |       <seriesInfo name="RFC" value="6151"/>
328 |       <seriesInfo name="DOI" value="10.17487/RFC6151"/>
329 |     </reference>
330 |   </references>
331 | 
332 |   <section anchor="appendix-a" title="Security Considerations">
333 |     <t>
334 | There are a number of security considerations to take into account when
335 | implementing or utilizing this specification.
336 | 
337 | TBD
338 |     </t>
339 |   </section>
340 |   <section anchor="appendix-c" title="Test Values">
341 | 
342 |     <t>
343 | The multihash examples are chosen to show different hash functions and
344 | different hash digest lengths at play. The input test data for all of the
345 | examples in this section is: <figure><artwork>Merkle–Damgård</artwork></figure>
346 |     </t>
347 | 
348 |     <section anchor="tv-sha1" title="SHA-1">
349 |       <t><figure><artwork>
350 | 0x11148a173fd3e32c0fa78b90fe42d305f202244e2739
351 |       </artwork></figure></t>
352 |       <t>
353 | The fields for this multihash are - hashing function: sha1 (0x11),
354 | length: 20 (0x14), digest: 0x8a173fd3e32c0fa78b90fe42d305f202244e2739
355 |       </t>
356 |     </section>
357 | 
358 |     <section anchor="tv-sha256" title="SHA-256">
359 |       <t><figure><artwork>
360 | 0x122041dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8
361 |       </artwork></figure></t>
362 |       <t>
363 | The fields for this multihash are - hashing function: sha2-256 (0x12),
364 | length: 32 (0x20), digest: 0x41dd7b6443542e75701aa98a0c235951a28a0d851b11564d20022ab11d2589a8
365 |       </t>
366 |     </section>
367 | 
368 |     <section anchor="tv-sha512-256" title="SHA-512/256">
369 |       <t><figure><artwork>
370 | 0x132052eb4dd19f1ec522859e12d89706156570f8fbab1824870bc6f8c7d235eef5f4
371 |       </artwork></figure></t>
372 |       <t>
373 | The fields for this multihash are - hashing function: sha2-512 (0x13),
374 | length: 32 (0x20),
375 | digest: 0x52eb4dd19f1ec522859e12d89706156570f8fbab1824870bc6f8c7d235eef5f4
376 |       </t>
377 |     </section>
378 | 
379 |     <section anchor="tv-sha512" title="SHA-512">
380 |       <t><figure><artwork>
381 | 0x134052eb4dd19f1ec522859e12d89706156570f8fbab1824870bc6f8c7d235eef5f4c2cbbafd365f96fb12b1d98a0334870c2ce90355da25e6a1108a6e17c4aaebb0
382 |       </artwork></figure></t>
383 |       <t>
384 | The fields for this multihash are - hashing function: sha2-512 (0x13),
385 | length: 64 (0x40),
386 | digest: 0x52eb4dd19f1ec522859e12d89706156570f8fbab1824870bc6f8c7d235eef5f4c2cbbafd365f96fb12b1d98a0334870c2ce90355da25e6a1108a6e17c4aaebb0
387 |       </t>
388 |     </section>
389 | 
390 |     <section anchor="tv-blake2b512" title="blake2b512">
391 |       <t><figure><artwork>
392 | 0xb24040d91ae0cb0e48022053ab0f8f0dc78d28593d0f1c13ae39c9b169c136a779f21a0496337b6f776a73c1742805c1cc15e792ddb3c92ee1fe300389456ef3dc97e2
393 |       </artwork></figure></t>
394 |       <t>
395 | The fields for this multihash are - hashing function: blake2b-512 (0xb240),
396 | length: 64 (0x40),
397 | digest: 0xd91ae0cb0e48022053ab0f8f0dc78d28593d0f1c13ae39c9b169c136a779f21a0496337b6f776a73c1742805c1cc15e792ddb3c92ee1fe300389456ef3dc97e2
398 |       </t>
399 |     </section>
400 | 
401 |     <section anchor="tv-blake2b256" title="blake2b256">
402 |       <t><figure><artwork>
403 | 0xb220207d0a1371550f3306532ff44520b649f8be05b72674e46fc24468ff74323ab030
404 |       </artwork></figure></t>
405 |       <t>
406 | The fields for this multihash are - hashing function: blake2b-256 (0xb220),
407 | length: 32 (0x20),
408 | digest: 0x7d0a1371550f3306532ff44520b649f8be05b72674e46fc24468ff74323ab030
409 |       </t>
410 |     </section>
411 | 
412 |     <section anchor="tv-blake2s256" title="blake2s256">
413 |       <t><figure><artwork>
414 | 0xb26020a96953281f3fd944a3206219fad61a40b992611b7580f1fa091935db3f7ca13d
415 |       </artwork></figure></t>
416 |       <t>
417 | The fields for this multihash are - hashing function: blake2s-256 (0xb260),
418 | length: 32 (0x20),
419 | digest: 0xa96953281f3fd944a3206219fad61a40b992611b7580f1fa091935db3f7ca13d
420 |       </t>
421 |     </section>
422 | 
423 |     <section anchor="tv-blake2s128" title="blake2s128">
424 |       <t><figure><artwork>
425 |         0xb250100a4ec6f1629e49262d7093e2f82a3278
426 |       </artwork></figure></t>
427 |       <t>
428 | The fields for this multihash are - hashing function: blake2s-128 (0xb250),
429 | length: 16 (0x10), digest: 0x0a4ec6f1629e49262d7093e2f82a3278
430 |       </t>
431 |     </section>
432 | 
433 |   </section>
434 |   <section anchor="acknowledgements" title="Acknowledgements">
435 |     <t>
436 | The editors would like to thank the following individuals for feedback on and
437 | implementations of the specification (in alphabetical order).
438 |     </t>
439 |   </section>
440 |   <section anchor="appendix-d" title="IANA Considerations">
441 |     <section anchor="mh-registry" title="The Multihash Identifier Registry">
442 |       <t>
443 |         The Multihash Identifier Registry contains hash functions supported by Multihash
444 |         each with its canonical name, its value in hexadecimal notation, and its status.
445 |         The following initial entries should be added
446 |         to the registry to be created and maintained at (the suggested URI)
447 |         <eref target="http://www.iana.org/assignments/multihash-identifiers">http://www.iana.org/assignments/multihash-identifiers</eref>:
448 |       </t>
449 | 
450 |       <texttable anchor="mh-registry-table" title="Multihash Identifier Registry">
451 |         <ttcol align="center">Name</ttcol>
452 |         <ttcol align="center">Identifier</ttcol>
453 |         <ttcol align="center">Status</ttcol>
454 |         <ttcol align="center">Specification</ttcol>
455 | 
456 |         <c>identity</c><c>0x00</c><c>active</c><c>Unknown</c>
457 |         <c>sha1</c><c>0x11</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
458 |         <c>sha2-256</c><c>0x12</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
459 |         <c>sha2-512</c><c>0x13</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
460 |         <c>sha3-512</c><c>0x14</c><c>active</c><c><xref target="FIPS202">FIPS 202</xref></c>
461 |         <c>sha3-384</c><c>0x15</c><c>active</c><c><xref target="FIPS202">FIPS 202</xref></c>
462 |         <c>sha3-256</c><c>0x16</c><c>active</c><c><xref target="FIPS202">FIPS 202</xref></c>
463 |         <c>sha3-224</c><c>0x17</c><c>active</c><c><xref target="FIPS202">FIPS 202</xref></c>
464 |         <c>sha2-384</c><c>0x20</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
465 |         <c>sha2-256-trunc254-padded</c><c>0x1012</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
466 |         <c>sha2-224</c><c>0x1013</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
467 |         <c>sha2-512-224</c><c>0x1014</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
468 |         <c>sha2-512-256</c><c>0x1015</c><c>active</c><c><xref target="RFC6234">RFC 6234</xref></c>
469 |         <c>blake2b-256</c><c>0xb220</c><c>active</c><c><xref target="RFC7693">RFC 7693</xref></c>
470 |         <c>poseidon-bls12_381-a2-fc1</c><c>0xb401</c><c>active</c><c><xref target="POSEIDON">POSEIDON</xref></c>
471 |       </texttable>
472 | 
473 |       <t>
474 | NOTE: The most up to date place for developers to find the table above, plus
475 | all multihash headers in "draft" status, is
476 | <eref target="https://github.com/multiformats/multicodec/blob/master/table.csv">https://github.com/multiformats/multicodec/blob/master/table.csv</eref>.
477 |       </t>
478 |     </section>
479 | 
480 |     <section anchor="mh-digest-algorithm" title="The 'mh' Digest Algorithm">
481 |       <t>
482 |         This memo registers the "mh" digest-algorithm in the
483 |         <eref target="https://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml">HTTP Digest Algorithm Values</eref>
484 |         registry with the following values:
485 |       </t>
486 | 
487 |         <t>Digest Algorithm: mh</t>
488 |         <t>Description: The multibase-serialized value of a multihash-supported algorithm.</t>
489 |         <t>References: this document</t>
490 |         <t>Status: standard</t>
491 | 
492 |     </section>
493 | 
494 |     <section anchor="mh-ni-hash-algorithm" title="The 'mh' Named Information Hash Algorithm">
495 |       <t>
496 |         This memo registers the "mh" hash algorithm in the
497 |         <eref target="https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg">Named Information Hash Algorithm</eref>
498 |         registry with the following values:
499 |       </t>
500 | 
501 |         <t>ID: 49</t>
502 |         <t>Hash Name String: mh</t>
503 |         <t>Value Length: variable</t>
504 |         <t>Reference: this document</t>
505 |         <t>Status: current</t>
506 | 
507 |     </section>
508 |   </section>
509 | </back>
510 | </rfc>


--------------------------------------------------------------------------------