[noise] XOFs (was Re: Notes from CRYPTO)

[Trevor Perrin]

On Tue, Sep 12, 2017 at 9:48 AM, Peter Schwabe <peter at cryptojedi.org> wrote:

>
> At the moment, all XOF and
> hash code of Kyber is in fips202.c, so it's somewhat separated from the
> rest of Kyber.
>
[...]

> I think the clean version is to have one XOF with a suitable API and
> then use that XOF for all (fixed-length or variable-length) hashes.
>
[...]

> If you decide to design a SHA-2-based XOF, then this might be worth a
> separate writeup, because people do want XOFs and some people like SHA-2
>


OK, let's assume:
 * PQ algorithms are willing to get their symmetric crypto by calling an
external function
 * Kyber's use of an "XOF" for symmetric crypto is representative of other
PQ algorithms

In Noise, we'd like to supply this XOF with our existing symmetric crypto,
e.g. by using HKDF as an "XOF".

But it's possible that PQ algorithms will popularize sponge-based XOFs, in
which case Noise might look old-fashioned or inefficient if we require HKDF
even with crypto algorithms like Keccak, while most PQ algorithms recommend
cSHAKE.

And if we have to align HKDF with XOFs anyways, it's worth discussing
something I was opposed to in past:  Could we adapt XOFs to serve the HKDF
role?  For example, allow a user to specify an XOF instead of a hash as the
final component of a Noise protocol name?

I'm imagining this as an optional use, e.g. you could still specify SHA3
(or BLAKE2) to use the existing HKDF design, but we could *also* allow
people to directly specify an XOF algorithm that doesn't need HKDF.

But what is an XOF?

The cSHAKE-based XOF Kyber uses has:
 - INPUT: pair of byte sequences (customization, input)
 - OUTPUT: byte sequence of arbitrary (and incrementally extensible) length.

Noise uses HKDF to produce a similar output from:
 - INPUT: pair of byte sequences (salt, input), where the salt is sometimes
a PRF key.

Maybe the union of these functionalities would be a keyed, customizable
XOF?  E.g.
 * HKDF where customization = HKDF.info and key = HKDF.salt
 * NIST's KMACXOF, i.e. "KMAC with Arbitrary-Length Output" from SP800-185?
 * BLAKE2X with customization = BLAKE2.personalization and key =
BLAKE2.salt?

I'm not at all sure these functions are sufficiently compatible, or the
assumptions at top are correct.  And I'm generally nervous that plugging in
such a complex crypto object might result in different interpretations
which wouldn't exist with a simple HASH interface and fixed HKDF
construction...

But, other thoughts?

Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170915/6388c5ac/attachment.html>