<div dir="ltr"><div><br></div><div>Hi all,</div><div><br></div><div>At the CRYPTO conference I discussed Noise with several people, in particular Peter Schwabe, Douglas Stebila, and Mike Hamburg.</div><div><br></div><div>Here's some points that emerged about post-quantum crypto (like Kyber), and STROBE (as in David Wong's "Disco" approach to Noise + Strobe):</div><div><br></div><div><br></div><div>Post-quantum algorithms and XOFs</div><div>-------------</div><div>Many post-quantum algorithms require a sort of KDF or XOF ("extensible output function") which takes a small symmetric key (e.g. 32 bytes) and expands it to a larger number of bytes.  For example, Kyber specifies SHAKE-128, a Keccak-based XOF [1].</div><div><br></div><div>It's not clear how we're going to harmonize the symmetric-crypto inside these PQ algorithms with the symmetric-crypto in the rest of Noise.  For example, if we follow the Kyber spec literally, then Kyber would *always* use SHAKE-128 internally, regardless of the hash choice made for the Noise protocol.</div><div><br></div><div>But if you're doing, say, Noise_XX+hfs_25519+Kyber_AESGCM_SHA256, you might prefer to use SHA256 internally to Kyber.  This requires turning SHA256 into an XOF, which isn't hard with HMAC or HKDF, but leads to questions:</div><div> - Do we need to coordinate this with Kyber authors (and other PQ authors?)  Or will these PQ algorithms have an interface for plugging in an external XOF?  </div><div> - Are there key-reuse / domain separation concerns if we allow a static PQ key to be used with different XOFs?</div><div> - If we specify an HMAC or HKDF construction, do we apply that consistently to all hash functions (annoying some people again that we're not using the Keccak and BLAKE2 designers' chosen XOF), or do we allow/require this to be specialized for certain hashes?</div><div><br></div><div>There's a lot of options, so it's hard to know what's best.  Any thoughts are welcome.</div><div><br></div><div><br></div><div>STROBE</div><div>-------</div><div> * For nonce-based AEAD, I think it seemed simplest to just copy the Strobe state containing the key, then feed in the nonce ("AD" operation?), followed by plaintext or ciphertext. </div><div><br></div><div> * Mike didn't seem to think that Strobe's "RATCHET" operation was ideal for Noise's Rekey.  I didn't follow all his reasoning, but Section B.2 of [2] discusses one limitation to "RATCHET", and mentions just using "PRF" to output a new key, which might suffice.</div><div><br></div><div>Trevor</div><div><br></div><div>[1] <a href="https://eprint.iacr.org/2017/634.pdf">https://eprint.iacr.org/2017/634.pdf</a></div><div>[2] <a href="https://eprint.iacr.org/2017/003.pdf">https://eprint.iacr.org/2017/003.pdf</a> </div><div><br></div></div>