[noise] PSK-based resumption, postquantum, and XOFs

[Trevor Perrin]

On Tue, Nov 28, 2017 at 9:05 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>> KMAC is more complicated than the above SHAKE-based "PRF" in a few ways:
>>
>>  (1) The first block of KMAC absorbs the string "KMAC" and an optional
>> user-specified customization string.
>
> This is the customization string of cSHAKE
>
>
>>  (2) The second block of KMAC absorbs the key, with a length prefix
>> (this is similar to the first block of "PRF", except for the added
>> length prefix).
>
> yeah this is part of the encoding/padding which you have to use (or at
> least something similar)

I'm arguing we *don't* need to hash this length field, or any of the 6
length fields (and extra name/customization block) that KMAC adds:
 - two length fields to indicate padding in first and second blocks
 - two for the name "KMAC" and customization string
 - one for the key length
 - one for output length

(also annoying, IMO: the cSHAKE/KMAC length fields are all
variable-length, with an initial length byte giving the length field's
length, sometimes at the beginning of the field, sometimes at the
end).


>>  (3) At the end, KMAC contains the desired output length (or 2-bytes
>> of zeros if you want a SHAKE-style arbitrary-length output stream).
>
> SHAKE also takes a desired output length if I'm reading the FIPS 202
> spec correctly. Although I've seen it implemented by just allowing you
> to read forever.

SHAKE doesn't hash the output length.  KMAC does, but KMACXOF sets it
to zero to produce a SHAKE-like output stream.


>>  (3) Instead of using the output-length field, it seems easier to use
>> SHAKE-style arbitrary-length output, and just take however many bytes
>> we need.
>>
>
> in the end implementers might have access to a SHAKE API that just
> takes an output length. Depending on the implementation they end up
> with.

If implementers only have a SHAKE API then we definitely don't want
KMAC, since KMAC can't be implemented using SHAKE (different values
for last two bits).

KMAC and SHAKE can both be implemented using cSHAKE, since NIST has
defined - as a special case - for cSHAKE with empty name and
customization-string to equal SHAKE.  So perhaps NIST expects cSHAKE
APIs to be widely available.


Anyways, this is more complicated and less obvious than I was hoping.

I guess the NIST PQ submissions are due in a couple days.  Once those
are published we can look at (how/if) the different PQ designers are
using XOFs, and maybe we'll hear more from NIST about this, so perhaps
this will get clearer in next few months.


Trevor