<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 9:48 AM, Peter Schwabe <span dir="ltr"><<a href="mailto:peter@cryptojedi.org" target="_blank">peter@cryptojedi.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>At the moment, all XOF and<br>
hash code of Kyber is in fips202.c, so it's somewhat separated from the<br>
rest of Kyber.<br></blockquote><div>[...] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think the clean version is to have one XOF with a suitable API and<br>
then use that XOF for all (fixed-length or variable-length) hashes.<br></blockquote><div>[...] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you decide to design a SHA-2-based XOF, then this might be worth a<br>
separate writeup, because people do want XOFs and some people like SHA-2<br></blockquote><div><br></div><div><br></div><div>OK, let's assume:</div><div> * PQ algorithms are willing to get their symmetric crypto by calling an external function</div><div> * Kyber's use of an "XOF" for symmetric crypto is representative of other PQ algorithms</div><div><br></div><div>In Noise, we'd like to supply this XOF with our existing symmetric crypto, e.g. by using HKDF as an "XOF".</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>But what is an XOF?</div><div><br></div><div>The cSHAKE-based XOF Kyber uses has:</div><div> - INPUT: pair of byte sequences (customization, input)</div><div> - OUTPUT: byte sequence of arbitrary (and incrementally extensible) length.</div><div><br></div><div>Noise uses HKDF to produce a similar output from:</div><div> - INPUT: pair of byte sequences (salt, input), where the salt is sometimes a PRF key.</div><div><br></div><div>Maybe the union of these functionalities would be a keyed, customizable XOF?  E.g.</div><div> * HKDF where customization = HKDF.info and key = HKDF.salt</div><div> * NIST's KMACXOF, i.e. "KMAC with Arbitrary-Length Output" from SP800-185?</div><div> * BLAKE2X with customization = BLAKE2.personalization and key = BLAKE2.salt?</div><div><br></div><div>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...</div><div><br></div><div>But, other thoughts?</div><div><br></div><div>Trevor</div><div> </div></div></div></div>