-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blake2b algorithm identifier #364
Comments
I haven't gotten around to making the pull request yet, but, in light of the inventory size concerns discussed in #367, perhaps multiple different blake2b output sizes should be supported? |
RFC7693 sec 4 "Standard Parameter Sets and Algorithm Identifiers" suggests identifiers |
If multiple sizes were to be supported, would you expect the client reading blake2b digests would know which size were used simply by looking at the size of the output hex-encoded digest? Or would that be indicated by different values used to specify different sizes? That seems inadvisable. Ref #371, I think the left column table of digests is meant to be a controlled vocabulary of digests, so if you wanted metadata to say what bytesize blake2b were used, I guess you'd need to list each allowed byte size in that table, with a string indicating it. |
multihash may be relevant here, but perhaps too untested/niche for use in OCFL? |
We looked into multihash, but felt that it introduced a dependency into the stack that detracted from the interoperability of using 'pure' hash algorithms. One of the design parameters for OCFL is that it should be usable in a default OS installation, with some built-in future-proofing ( |
refs #371 |
blake2b
is listed in the digest algorithm table, but the output size is not specified. The notes say "full-length form only," which I assume meansblake2b-512
. For the sake of clarity and interpretability, I think it would be useful to use the complete identifier.The text was updated successfully, but these errors were encountered: