You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the Wikipedia page on SHA-3 SHAKE128/256 are parameterised functions that need to have an output digest length specified. As of now I'm unsure how they are actually meant to work with multihash (I will try and look into existing libraries and list what they do soon done); potentially the digest length given with the multihash could be used, but that should probably be specified explicitly since it's a special case compared to how the length would be used with other hash types.
Similarly adding support for other Keccac variants as proposed in #54 may have the same issue since Keccac is designed to have an arbitrary length output.
That is ever so slightly different behaviour from how I understand that length is used for other variants as Keccac allows for increasing the output length longer than the standard length for the variant, all other algorithms have a fixed size output and the length specifies to just use a prefix of that output for comparison purposes.
That is ever so slightly different behaviour from how I understand that length is used for other variants as Keccac allows for increasing the output length longer than the standard length for the variant, all other algorithms have a fixed size output and the length specifies to just use a prefix of that output for comparison purposes.
Came here to say this. I think it needs a dedicated ticket.
@indolering I don't understand. Multihashes carry the length part not to store the default length of a hash, but precisely to store arbitrary hash lengths which cannot be guessed directly from the hash type. How does using it to specify arbitrary lengths makes it an special behaviour?
to store arbitrary hash lengths which cannot be guessed directly from the hash type
That may be how you have interpreted the spec, but it doesn't actually ascribe a meaning to the length. For fixed output-length hash functions it has been stated in comments (on issue #1 I think) that this is a simple truncation. There have also been comments on other issues about what to do if the length is greater than the length supported by the hash.
SHAKE/Keccac are different to all the other hash functions in that the output length is an input to the function. This will at the very least require different handling in the implementations to the fixed-length functions, so should be commented on in the spec to ensure all implementations behave compatibly.
That may be how you have interpreted the spec, but it doesn't actually ascribe a meaning to the length.
mm yeah... you're right now that I think of it. The problem in the end is that multihashes don't carry generation parameters (#78) so the length varint becomes ambiguous for these hash functions (i.e. truncation is a good example). There's a proposal that would address these: multiformats/multiformats#37
Activity
Nemo157 commentedon Nov 3, 2016
Well, that was disappointing.
Kubuxu commentedon Nov 3, 2016
Multihash stores also length of the hash, in case that Keccac the length would be taken from that length.
Nemo157 commentedon Nov 3, 2016
That is ever so slightly different behaviour from how I understand that length is used for other variants as Keccac allows for increasing the output length longer than the standard length for the variant, all other algorithms have a fixed size output and the length specifies to just use a prefix of that output for comparison purposes.
indolering commentedon Mar 19, 2017
Came here to say this. I think it needs a dedicated ticket.
hsanjuan commentedon Mar 21, 2017
@indolering I don't understand. Multihashes carry the
lengthpart not to store the default length of a hash, but precisely to store arbitrary hash lengths which cannot be guessed directly from the hash type. How does using it to specify arbitrary lengths makes it an special behaviour?Nemo157 commentedon Mar 21, 2017
That may be how you have interpreted the spec, but it doesn't actually ascribe a meaning to the length. For fixed output-length hash functions it has been stated in comments (on issue #1 I think) that this is a simple truncation. There have also been comments on other issues about what to do if the length is greater than the length supported by the hash.
SHAKE/Keccac are different to all the other hash functions in that the output length is an input to the function. This will at the very least require different handling in the implementations to the fixed-length functions, so should be commented on in the spec to ensure all implementations behave compatibly.
hsanjuan commentedon Mar 22, 2017
mm yeah... you're right now that I think of it. The problem in the end is that multihashes don't carry generation parameters (#78) so the length varint becomes ambiguous for these hash functions (i.e. truncation is a good example). There's a proposal that would address these: multiformats/multiformats#37