Add blake3 as a registered/supported hash algorithm. #1240
Conversation
rchincha
requested review from
jonjohnsonjr,
stevvooe,
sudo-bmitch,
sajayantony,
tianon and
cyphar
as code owners
rchincha
force-pushed
the
blake3
branch
4 times, most recently
from
8faee6e to
16811ee
Compare
rchincha
force-pushed
the
blake3
branch
2 times, most recently
from
2733aae to
a2ce39a
Compare
There was a problem hiding this comment.
A minor typo fix (wrong number of bits in the regex 🙈), a little whitespace pedanticism (that I'm hoping @sudo-bmitch will confirm or reject/deny), and what can probably/hopefully just be a discussion of the URL to link to (not necessarily requesting any change there).
Overall the change looks good and I'm +1; thanks for taking a stab!
rchincha
force-pushed
the
blake3
branch
2 times, most recently
from
b20ba52 to
139e306
Compare
| @@ -161,6 +162,16 @@ Implementations MAY implement SHA-512 digest verification for use in descriptors | |||
| When the _algorithm identifier_ is `sha512`, the _encoded_ portion MUST match `/[a-f0-9]{128}/`. | |||
| Note that `[A-F]` MUST NOT be used here. | |||
|
|
|||
| #### BLAKE3 | |||
There was a problem hiding this comment.
In addition to the new section, you'll want a new entry in the registered-algorithms table up around line 140, right?
descriptor.md
Outdated
| @@ -220,3 +231,5 @@ In the following example, the descriptor indicates the type of artifact it is re | |||
| [rfc7230-s2.7]: https://tools.ietf.org/html/rfc7230#section-2.7 | |||
| [sha256-vs-sha512]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/hsMw7cAwrZE | |||
| [iana]: https://www.iana.org/assignments/media-types/media-types.xhtml | |||
| [blake3]: https://github.com/C2SP/C2SP/blob/main/BLAKE3.md | |||
There was a problem hiding this comment.
Spinning out of this earlier thread:
Linking to the https://github.com/BLAKE3-team/BLAKE3-specs or https://github.com/C2SP/C2SP/blob/main/BLAKE3.md would each make sense to me.
I'm not an approver, so feel free to ignore me, but personally, having a versioned spec that links to a floating document makes me a bit concerned about image-spec v1.2.0 (or whatever image-spec release eventually ships this registration) being a moving target. Can we pin a specific version of the BLAKE3 spec, e.g. via their BLAKE3/v1.0.0 tag with https://github.com/C2SP/C2SP/blob/BLAKE3/v1.0.0/BLAKE3.md ? It currently matches their main content for that file, and if they tweak the file in the future, e.g. with a BLAKE3/v1.1.0, or dev work in preparation for such a release, it wouldn't get retroactively sucked into image-spec v1.2.0, and would take explicit decisions by image-spec maintainers and implementors to pull in whatever the new BLAKE3 changes were.
Motivations for this PR: 1. Blake3 is a high performance hash and there is growing community interest 2. Blake3 is variable output but mandate 256-bit output Signed-off-by: Ramkumar Chinchani <rchincha.dev@gmail.com>
|
|
||
| [BLAKE3][blake3] is a high performance, highly parallelizable, collision-resistant hash function which [is more performant][blake3-vs-sha2] than | ||
| [SHA-256][rfc4634-s4.1]. | ||
| The hash output length MUST be 256 bits. |
There was a problem hiding this comment.
I'm not familiar with BLAKE3, but going through the spec, it seems like we might also need to specify the hash hashing mode? Or is it sufficiently obvious from the context that there's no provision for supplying a key or other input, making the keyed_hash and derive_key modes unfeasible?
Motivations for this PR: