[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [Cfrg] Recommended bit length before truncating a hash mod p
From:       Markku-Juhani Olavi Saarinen <mjos () iki ! fi>
Date:       2019-03-22 15:30:22
Message-ID: CA+iU_q=wacCkqDV8jr8dmSSSTU_PTodAsajSSPUa=hmDr6mEQg () mail ! gmail ! com
[Download RAW message or body]

Gilles,

Thanks for clarifications. The name Keccak, of course, is entirely
appropriate when we discuss the family of cryptographic primitives,
the permutation, and other internal hashing operations.

> 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.

It is indeed very unfortunate that adding these padding suffix bits is
not possible via the byte-oriented API calling interfaces commonly in
use. Therefore a higher-level "Keccak" primitive -- as understood and
used by the cryptocurrency people -- can only rarely be used to
compute an SHA-3 hash.

Cheers,
- markku

Dr. Markku-Juhani O. Saarinen <mjos@iki.fi>

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]