[noise] Notes from CRYPTO

[Peter Schwabe]

Trevor Perrin <trevp at trevp.net> wrote:
> Hi all,

Hi Trevor, hi all,

> Post-quantum algorithms and XOFs
> -------------
> 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].
> 
> 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.
> 
> 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:
>  - 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?

I don't think you'll have to coordinate that. At the moment, all XOF and
hash code of Kyber is in fips202.c, so it's somewhat separated from the
rest of Kyber. There are two different ways how the XOF is used, though:
at some spots we know the output length at compile time (e.g., 256 bits
or 768 bits), but when expanding the seed into the matrix we do
rejection sampling which really uses the feature of the XOF that we can
keep generating output until we have enough (where "enough" depends on
the output and is thus only known at compile time).

>  - Are there key-reuse / domain separation concerns if we allow a
>  static PQ key to be used with different XOFs?

You would want to use the same secret key to generate different public
keys using different XOFs? You cannot use the same public key with
different XOFs, because the public key is of the format (seed,As+e),
where A is XOF(seed), so it depends on the choice of XOF.

>  - 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?

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. The
runtime-variable-length hashing requires an incremental API for output;
Kyber is happy to not have an incremental API for input. What XOF you
use internally shouldn't matter to PQ designers, although they almost
certainly have a preference. 

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
(in particular because there's hardware support on various platforms).

Cheers,

Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170912/1f1588ad/attachment.sig>