Re: [CFRG] Extract-and-expand with KMAC

[Gilles VAN ASSCHE <[e-mail]>]

Hi,

> "Dang, Quynh H. (Fed)" <[e-mail]> wrote:
>> I am not aware of a protocol where the output from an extract step:
>> PRK is saved and the expansion step gets executed later to generate 
>> keys.

> Totally agreed! in most cases, we don't worry much about PRK. Note, however, that the message I was responding to explicitly *did* worry about it:

> Gilles VAN ASSCHE <[e-mail]> wrote:
>> This solution is not incompatible with the case where an intermediate 
>> value PRK is required:

> If indeed the intermediate value is required, as discussed here, then my concerns about non--black-box use of the primitives are relevant.
> Otherwise, as you say, no worries at all---and we have good reason to believe that constructions like SHA-3 are great for such cases.

Indeed, my primary message was that the intermediate value PRK is probably (=without knowledge of the application) not needed, and therefore evaluating SHAKE128(salt ; IKM ; info) works as is. So I guess we agree on this point.

I understand your concerns about the non-black-box use of SHAKE. However, it seems to me they would be addressed with an implementation that supports Init-Update-Final-like (IUF) function calls. The PRK would then materialize as the state (e.g., the struct passed to these functions) after Update(salt ; IKM). Note that I am not advocating this mechanism, but just using it to argue that
- the PRK exists so philosophically SHAKE is also somehow doing extract+expand and
- it is not unreasonable to expose the PRK with an IUF implementation, should the need of a delayed expansion occurs.

Kind regards,
Gilles