sha3: move SHAKE into separate shake crate

[newpavlov]

No description provided.

[tarcieri]

I understand moving turboshake into its own crate as it's not standardized, and cshake seems fine as it's not technically part of FIPS 202 (though it is in NIST SP 800-185), but SHAKE128 and SHAKE256 are formally part of the SHA-3 family as defined in FIPS 202, so I'm not sure I understand the value of splitting them out like this. It feels like more crates for the sake of more crates, when we already have an excessive number of crates.

[newpavlov]

Most users probably use only the fixed size types and the SHAKE implementation does not share much with them, so it allows to make sha3 crate smaller (both LoC and public API wise) and re-export only the Digest trait similarly to the most other hash crates. In other words, I think it makes sense to keep XOF and non-XOF algorithms in separate crates.

To keep the number of crates the same I considered merging cshake into shake in a later PR, similarly to how ascon-xof128 and k12 contain both customized and non-customized variants.

SHAKE128 and SHAKE256 are formally part of the SHA-3 family as defined in FIPS 202

Well, considering that we have the Keccak variants, the sha3 crate is not strictly "implementation of FIPS 202".

[tarcieri]

I would guess the opposite: SHAKE is likely to be the main thing people consume from this crate, owing to its use in various standards. But I guess we can do a survey.

The actual SHA-3 hash functions have generally received poor adoption owing to their poor speed.

Well, considering that we have the Keccak variants, the sha3 crate is not strictly "implementation of FIPS 202".

If we're removing things from sha3, I would prioritize things which aren't defined in FIPS 202 and therefore technically part of the SHA-3 family.

[newpavlov]

But I guess we can do a survey.

I clicked through a number of most downloaded non-RustCrypto dependents and on the first glance most use fixed size types (with a surprising popularity of the Keccak variants owning to the cryptocoin stuff). I will try to do a proper survey later.

If we're removing things from sha3, I would prioritize things which aren't defined in FIPS 202 and therefore technically part of the SHA-3 family.

I understand this position, but in practice it would result in pure code duplication. Granted, it's not much thanks to keccak and sponge-cursor crates, but still.

[tarcieri]

Aah right, even as a user thereof I forgot about that. I guess I should probably say I would expect SHAKEs are the most used of the actually FIPS 202 constructions.

[newpavlov]

I would expect SHAKEs are the most used of the actually FIPS 202 constructions.

They use only SHAKEs without the fixed size variants, no? IMO it's another argument for splitting XOF and non-XOF constructions since they are unlikely to be mixed.

[tarcieri]

If XOFs were actually in a separate repo, I think that'd be a good argument for splitting it out

[newpavlov]

I am fine with the repo split, if you prefer to handle it such way.

[tarcieri]

I think it might make SHAKE harder to find, but it would at least be a justification for splitting them

[newpavlov]

I will merge this PR and will do the repo split then. To improve discoverability I will mention the XOFs repo in the hashes root README.