SHAKE128/256 are not fully specified

[Nemo157]

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.

[Nemo157]

• Doesn't implement the SHA-3 variants
  • go-multihash
  • js-multihash
  • clj-multihash
  • dignifiedquire/rust-multihash
  • google/rust-multihash
  • haskell-multihash
  • python-multihash
  • elixir-multihash
  • elixir-multihashing
  • SwiftMultihash
  • ruby-multihash
  • scala-multihash
  • php-multihash
• Implements the SHA-3 variants but doesn't support them
  • MultiHash.Net

Well, that was disappointing.

[Kubuxu]

Multihash stores also length of the hash, in case that Keccac the length would be taken from that length.

[Nemo157]

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]

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.

[hsanjuan]

@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?

[Nemo157]

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.

[hsanjuan]

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