As an example, both Classic-McEliece and Kyber KEMs produce 32 byte shared secrets. How convenient since that's exactly the size I need for an AES-256 key!

Is this safe to do? My question can be formalized into these (I believe) equivalent questions about the definition of KEMs (I'm mostly interested in NIST Round 3 PQC KEMs, but more general answers are ok too)

  1. Does an $X$-bit KEM shared secret contain $X$ bits of entropy?
  2. Are the bits of a KEM shared secret guaranteed to be IID?
  3. Can a KEM shared secret be used directly as a symmetric key?

Background to explain how I arrived at this question; not actually part of the question.

I am expecting the answer to be "No, you need to run the SS though a KDF", but I'm looking for citations to back that up. That would align with this answer that @poncho gave about ECDH, which would also be true of DH, but maybe those are not formally KEMs?:

  • 1
    $\begingroup$ Is there a reason you can't pass it through a KDF? Or are you just asking about the theory? Anyway I think those two algorithms you mentioned are actually defined as using a KDF to generate the shared secret. $\endgroup$ – forest May 4 at 23:34
  • $\begingroup$ @forest can't is a strong word, but it simplifies protocol design if I don't need a KDF as that's one more set of parameters I need to include. $\endgroup$ – Mike Ounsworth May 5 at 13:53

The algorithms you mentioned use a secure hash function to derive this convenient 32-byte shared secret, but it is not necessarily true that all KEMs will do so. The answer to your three general questions would thus be all "it depends on the actual algorithm". In general, they use KDFs.

The Kyber KEM submission, for example, uses SHAKE-256:

As a modification in round-2, we decided to derive the final key using SHAKE-256 instead of SHA3-256. This is an advantage for protocols that need keys of more than 256 bits. Instead of first requesting a 256-bit key from Kyber and then expanding it, they can pass an additional key-length parameter to Kyber and obtain a key of the desired length. This feature is not supported by the NIST API, so in our implementations we set the keylength to a fixed length of 32 bytes in api.h.

The McEliece submission uses the same hash function:

3.1 Parameter set kem/mceliece348864

KEM with $m = 12$, $n = 3488$, $t = 64$, $\ell = 256$.

Field polynomial $f(z) = z^{12} + z^3 + 1$.

Hash function: SHAKE256 with 32-byte output.

This parameter set is proposed and implemented in this submission.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.