Re: [Cfrg] Recommended bit length before truncating a hash mod p

[Gilles Van Assche <[e-mail]>]

Dear Markku,

> Some notes since this is a standardization forum:
>
> - It is generally not advisable to say "Keccak" when you mean SHA3.
> The padding mechanism was slightly changed from the "final competition
> round" Keccak 3.0 proposal to FIPS 202, making the two incompatible.

I agree with you on avoiding confusion between Keccak and SHA-3.

However, for the sake of completeness, I wanted to point out that the
padding scheme wasn't changed between the final-round proposal and the
FIPS 202 standard. As you know, the FIPS 202 functions are merely
appending a suffix to the input before calling the original final-round
proposal Keccak, for the purpose of domain separation between SHA-3 and
SHAKE.

> Some cryptocurrencies (e.g. Monero) actually use the obsolete
> pre-standardization version and talk of "Keccak" when they refer to it.

I wouldn't use qualifiers like pre- and post-standardization versions,
but instead say that SHA-3 and SHAKE are built on top of Keccak.
Alternatively, they are a subset of Keccak in the sense that only part
of its input space can be addressed through them.

> - FIPS 202 defines not only an actual SHA3-512 but also
> Extendable-Output Functions (XOFs) that allow hashes of any output
> size. The source code link provides a ExtendedKeccak(Hash) method
> which is a "doubly standard-violating" ad hoc construction, having
> nothing to do with the faster, standardized XOFs (SHAKE128 and SHAK256).

Indeed, referring back to the original discussion, having a XOF
interface would simplify the way some protocols are written. (I
deliberately wrote "XOF interface" to include both native XOFs and
traditional fixed-length hash functions with an MGF1-like mode. Of
course, I could only recommend to use native XOFs.)

Kind regards,
Gilles