Subject: [lamps] Which PQC KEMs can be used for composite encryption?

From: "Bruckert, Leonie" <[email-masked]>
Date: Wed, 15 Sep 2021 10:23:06 +0000

Hi,

I recently looked into the composite encryption described in draft-ounsworth-pq-composite-encryption, in particular option 2 (encryption and KEMs).

If I understood correctly, the data encryption key is split into at least two shares, each being encrypted/encapsulated under the respective component public key.

I was wondering which PQC KEMs can be used with this mode. A requirement mentioned in the draft is that

"all component KEMs MUST produce a shared secret whose bits
are independent and uniformly distributed (aka "uniformly IID"
or "uniformly random" or "full entropy") and therefore the shared
secret is safe to use directly as a symmetric key."

As far as I know, the NIST candidates are IND-CCA secure KEMs where the value being encapsulated is not directly used as shared secret. Instead it is fed into a hash function together with some other values (e.g. the public key) in order to receive the shared secret. Thus, I would conclude that these KEMs are not qualified.

So my question is: Do we know any PQC KEM that can be used with this mode?

If I use KEMs in a composite encryption mode, I certainly want them to be CCA secure so I can use the public key multiple times. Otherwise it won't make sense to put them in a certificate.

Please clarify if I am wrong with my thoughts.

Regards,
Leonie

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Sep 2021 21:53:06 +0300

On Wed, Sep 15, 2021 at 10:23:06AM +0000, Bruckert, Leonie wrote:
> 
> I recently looked into the composite encryption described in
> draft-ounsworth-pq-composite-encryption, in particular option 2
> (encryption and KEMs).
> 
> If I understood correctly, the data encryption key is split into at
> least two shares, each being encrypted/encapsulated under the
> respective component public key.
> 
> I was wondering which PQC KEMs can be used with this mode. A
> requirement mentioned in the draft is that
> 
> As far as I know, the NIST candidates are IND-CCA secure KEMs where
> the value being encapsulated is not directly used as shared secret.
> Instead it is fed into a hash function together with some other values
> (e.g. the public key) in order to receive the shared secret. Thus, I
> would conclude that these KEMs are not qualified.
> 

There are some other problems with this:

- Some KEMs produce shared secrets that are not the usual 256 bits.
  E.g., NISTPQC altenates FrodoKEM and SIKE can produce 128- or 192-bit
  shared secrets. And even if KEM drives its shared secret output
  directly off a XOF (e.g., NISTPQC finalist Kyber), allowing any output
  length, most implementations will not support that.

  And it is not just PQ KEMs, it is also what classical KEMs produce
  (I think at least some of those drive output from some hash function
  or XOF). And I do not have a handy list of classical KEMs.

- Some encryption modes are not safe with deterministic nonces (e.g.,
  GCM mode, especially with 128-bit keys). Which means either stuffing
  randomly generated nonce into the encrypted message, or coping with odd
  key lengths no KEM is going to be able to produce in practice.

-Ilari

---

From: Mike Ounsworth <[email-masked]>
Date: Wed, 15 Sep 2021 20:02:21 +0000

Hi Leonie, thanks for starting this discussion.

I guess the Too Long; Didn't Read here is: Can we assume a KDF is always included in a KEM encaps(), or do we need to do one explicitly as part of composite-encryption?

I think (but could be wrong) that CCA security is orthogonal to whether the KEM output (ie shared secret) can be used directly as a symmetric key, or if it needs to be run through a KDF first. For example, I could imagine a KEM that outputs an IND-CCA shared secret prefixed with a fixed version byte; you can't use that directly as a one-time-pad key because of the fixed version byte.

That security consideration text is there because we've been struggling to understand whether, with the KEM specifications that will be standardized by NIST, the KEM would be expected to output a shared secret that can be used directly as a one-time-pad (i.e. the bits of the shared secret are a random key). If I'm reading your email properly, you're advocating that a KEM's output should be hashed together with some protocol-level contextual values before it's used?

As an example of a PQC KEM that should work, Kyber (as per the Round 3 submission docs) has a KDF as the last step of the CCAKEM algorithm:
K := KDF(K||H(c))
So, it should be ok to be used directly in our scheme.

The same should be true of SIKE KEM (Round 3 SIKE spec 1.3.11 Algorithm 2 Encaps) as it also finishes by hashing everything.

The consensus at the LAMPS interim was to bring these discussions back to RSA-KEM (5990). The KEM shared secret Z is not itself IID, so they run it through a KDF (by itself) in Step 3 to be able to use it as a KEK.
KEK = KDF (Z, kekLen)
WK = Wrap (KEK, K)

So we have two examples of compatible KEMs, and one that isn't directly but could be made compatible. But we're not sufficiently expert in KEMs to know if this applies only to some PQC KEMs, to all PQC KEMs, or all KEMs present and future. Or, to your point, whether this is actually how KEM outputs are intended to be used, or if you need to hash them with protocol context values first. We believed, from looking at the Kyber and SIKE construction that an extra KDF step (and parameter) was unnecessary, but we're happy to add it if it improves security or makes this mode more generally applicable to more KEM primitives.

I am eager to hear from people more expert than myself in KEM constructions :)

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Bruckert, Leonie
Sent: September 15, 2021 5:23 AM
To: [email-masked]
Subject: [EXTERNAL] [lamps] Which PQC KEMs can be used for composite encryption?

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________

Hi,

"all component KEMs MUST produce a shared secret whose bits are independent and uniformly distributed (aka "uniformly IID"
or "uniformly random" or "full entropy") and therefore the shared secret is safe to use directly as a symmetric key."

Regards,
Leonie
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Bruckert, Leonie" <[email-masked]>
Date: Thu, 16 Sep 2021 06:12:19 +0000

Hi Mike,

Comments inline.

> I guess the Too Long; Didn't Read here is: Can we assume a KDF is always
> included in a KEM encaps(), or do we need to do one explicitly as part of
> composite-encryption?
> 
> I think (but could be wrong) that CCA security is orthogonal to whether the
> KEM output (ie shared secret) can be used directly as a symmetric key, or if it
> needs to be run through a KDF first. For example, I could imagine a KEM that
> outputs an IND-CCA shared secret prefixed with a fixed version byte; you
> can't use that directly as a one-time-pad key because of the fixed version
> byte.

I am not an expert in KEM constructions either, but this sounds plausible.

> 
> That security consideration text is there because we've been struggling to
> understand whether, with the KEM specifications that will be standardized
> by NIST, the KEM would be expected to output a shared secret that can be
> used directly as a one-time-pad (i.e. the bits of the shared secret are a
> random key). If I'm reading your email properly, you're advocating that a
> KEM's output should be hashed together with some protocol-level
> contextual values before it's used?

That is not what I was trying to say. I rather observed that a KDF or hash function is incorporated in the NIST KEMs. I try to explain my thoughts in the next paragraph.

> As an example of a PQC KEM that should work, Kyber (as per the Round 3
> submission docs) has a KDF as the last step of the CCAKEM algorithm:
> K := KDF(K||H(c))

Okay, let's take Kyber as an example, but you could easily think of another PQC KEM.
The 'K's in the formula above are actually not the same, so I added a '*' for clarification.

In 
K := KDF(K* || H(c)) 
K is the final key that is returned by Kyber. It may be used directly for encryption. K* is a random value that is chosen by Alice. K* is encapsulated by Alice resulting in a ciphertext. This ciphertext is transmitted to Bob. Bob runs the decapsulation and gets K*. Both Alice and Bob use the KDF to derive the key K.

Now consider a composite encryption scenario where Alice wants to send a message to Bob. 
Bob owns a composite public key consisting of two component keys. Let's assume that the first component key can be used with e.g. Kyber. 

According to the draft, the content encryption key is split into two shares: CEK = S1 XOR S2. This is achieved by generating a random S1 and calculating the second share as S2 = CEK XOR S1.
While writing this, I just noticed that I overlooked the case distinction in the encryption process described in the draft. So, I think I do not have a problem here anymore. In case of KEMs the share is not randomly chosen, but output of the encapsulation (S1 =  K).

Then I am totally fine. Sorry for causing confusion. I misleadingly assumed S1 = K* which is of course nonsense. 

Regards,
Leonie

> The same should be true of SIKE KEM (Round 3 SIKE spec 1.3.11 Algorithm 2
> Encaps) as it also finishes by hashing everything.
> 
> The consensus at the LAMPS interim was to bring these discussions back to
> RSA-KEM (5990). The KEM shared secret Z is not itself IID, so they run it
> through a KDF (by itself) in Step 3 to be able to use it as a KEK.
> KEK = KDF (Z, kekLen)
> WK = Wrap (KEK, K)
> 
> 
> So we have two examples of compatible KEMs, and one that isn't directly but
> could be made compatible. But we're not sufficiently expert in KEMs to know
> if this applies only to some PQC KEMs, to all PQC KEMs, or all KEMs present
> and future. Or, to your point, whether this is actually how KEM outputs are
> intended to be used, or if you need to hash them with protocol context
> values first. We believed, from looking at the Kyber and SIKE construction
> that an extra KDF step (and parameter) was unnecessary, but we're happy to
> add it if it improves security or makes this mode more generally applicable to
> more KEM primitives.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> I recently looked into the composite encryption described in draft-
> ounsworth-pq-composite-encryption, in particular option 2 (encryption and
> KEMs).
> 
> If I understood correctly, the data encryption key is split into at least two
> shares, each being encrypted/encapsulated under the respective
> component public key.
> 
> "all component KEMs MUST produce a shared secret whose bits are
> independent and uniformly distributed (aka "uniformly IID"
> or "uniformly random" or "full entropy") and therefore the shared secret is
> safe to use directly as a symmetric key."
> 
> As far as I know, the NIST candidates are IND-CCA secure KEMs where the
> value being encapsulated is not directly used as shared secret. Instead it is
> fed into a hash function together with some other values (e.g. the public
> key) in order to receive the shared secret. Thus, I would conclude that these
> KEMs are not qualified.
> 
> If I use KEMs in a composite encryption mode, I certainly want them to be
> CCA secure so I can use the public key multiple times. Otherwise it won't
> make sense to put them in a certificate.
> 
> -----BEGIN PGP SIGNATURE-----
> Comment: Using gpg4o v6.0.124.9651 - https://www.gpg4o.de/
> Charset: utf-8
> 
> iQIzBAEBCAAdFiEE3zFKr4OUJ0GHtLDCQlNDNDsJayMFAmFByYgACgkQQlNDN
> DsJ
> ayNu1w//W3mJD9LJ43KxEVv0t9etwv1Rw21ztRmb0biWskF1JJkxZIUmXBdb7
> MS9
> Sct7czMb/oNL/jrFqbiAHREwI2M5CVQ88v2YIGvA7T562amU3NBH/HbHZSwRe
> ByB
> nQlV+JmEEovHM75pasOEUGAYBVLG3smbRSNl0rQqk0hvCUPpWfuXxyVuxCY
> zaGu7
> XxvhfU0RSCE/e76xzf90WQQn1IylH8tCKrXST5+x+pxk2W2MkyNVzOqTBg7syc
> dg
> YJLLyK4aHm7emrlh6xOxSCVKVqsxKzGNV8/TRo/lvd3zhjTj6Ij5pLctBIgSHeA4
> rGSjqviKrMmFErnX3OeXgkPDNebQpxL0nrO7+vyJspzJ1C4SM2XQzvewjUSCa0
> gS
> 163eQI+ufvbEBp48BqGNcnrYPgjs+CIKvbcK4a5ETbtCT9HG+chED4v62x261YKw
> q6c6/1kEbd1hS3raaWKFEmhned2JP5WTGTu5/PARvA4hTqEaxnujBEF8qja3jz4
> Q
> NIwXSjtuOQGe+XVpNDGIYSCXDMWNSCdaDTXCuWuiWwYUvb5jad+qSpQCp
> nEe9AKB
> pQPgEV2Z0eIUB5FRBQwy27/ZWHzmL/VnJwb5MtuNg2cBNw+TBYCdaNo8KV
> 1uTeRP
> ASCIAvecw7809QAx4okUChvIBR/25qBJkGthNOLXnA9mqzINdGw=
> =Bqt8
> -----END PGP SIGNATURE-----
> Any email and files/attachments transmitted with it are confidential and are
> intended solely for the use of the individual or entity to whom they are
> addressed. If this message has been sent to you in error, you must not copy,
> distribute or disclose of the information it contains. Please notify Entrust
> immediately and delete the message from your system.

---

From: Kris Kwiatkowski <[email-masked]>
Date: Thu, 16 Sep 2021 14:21:47 +0100

On 9/15/21 9:02 PM, Mike Ounsworth wrote:
> But we're not sufficiently expert in KEMs to know if this applies only to some PQC KEMs, to all PQC KEMs, or all KEMs present and future.

The authors of "Separate Your Domains: NIST PQC KEMs, Oracle Cloning and 
Read-Only Indifferentiability" (Bellare, Davis, Gunther, EUROCRYPT 2020) looked
at the construction of NIST PQC KEMs. An orthogonal, but still contribution in
that paper is a "generic" framework to "unify and visualize" variations between KEM
constructions submitted to NIST PQC.
In the chapter 2.2, the "Algorithm KE_4" shows that output of a shared secret (K)
is constructed by calling random oracle H_4 and assigning it's output to K. Based
on that,  I would assume, that for all Round3 NIST PQC KEMs all bits of shared secret
are chosen uniformly.

> I am eager to hear from people more expert than myself in KEM constructions :)
Not an expert either.

BR,
Kris

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 16 Sep 2021 13:58:23 +0000

> So my question is: Do we know any PQC KEM that can be used with this 

I think we agree that we want something that can be used with any reasonable encryption or KEM primitive (even ones that haven't been invented yet), hence the requirement that this draft places on KEMs is too restrictive (even ignoring the valid points that Leonie brings up).

One obvious modification we could place on the draft is to send the output of any KEMs through a KDF.  Actually, sending everything through a KEM would mean that, even if only public key encryption algorithms are used, neither side could set the CEK to an arbitrary value.  The implicit API in the Generation Procedure doesn't support that (it assumes the CEK comes from the caller, that is, someone selects the value) - would it be an issue to change that?

Of course, the problem with specifying a KEM (apart from the added complexity) is that both sides need to agree on it.  One approach would be to have the public key contain a list of KDFs that the decryptor supports, and have the ciphertext include the KDF that the encryptor used.

Would this be a reasonable (if somewhat radical) change to the draft?

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 16 Sep 2021 14:31:09 +0000

Thank you for the review Leonie 😊

Maybe the wording (or variable names) of the encryption procedure could be improved for better readability. 

Here's a less formal description of the encryption procedure for mode 2; the intention is to transmit n encrypted values:

Input: CEK

# compute S1 .. Sn-1 and E1 .. En-1
for at least one encryption
  Si = CEK
  Ei = encrypt(CEK, Pi)

for each KEM (0 or more)
  Si, Ei = encaps(Pi)

En = CEK XOR S1 XOR S2 XOR ... XOR Sn-1

Output E1 ... En

We made the (maybe slightly odd) design decision that this mode requires at least one pure encryption scheme so that the inputted CEK can be directly encrypted. Not sure we love this design, but we submit it for discussion 😊

---
Mike Ounsworth

-----Original Message-----
From: Bruckert, Leonie <[email-masked]> 
Sent: September 16, 2021 1:12 AM
To: Mike Ounsworth <[email-masked]>; [email-masked]
Subject: [EXTERNAL] AW: Which PQC KEMs can be used for composite encryption?

Comments inline.

> I guess the Too Long; Didn't Read here is: Can we assume a KDF is 
> always included in a KEM encaps(), or do we need to do one explicitly 
> as part of composite-encryption?
> 
> I think (but could be wrong) that CCA security is orthogonal to 
> whether the KEM output (ie shared secret) can be used directly as a 
> symmetric key, or if it needs to be run through a KDF first. For 
> example, I could imagine a KEM that outputs an IND-CCA shared secret 
> prefixed with a fixed version byte; you can't use that directly as a 
> one-time-pad key because of the fixed version byte.

> 
> That security consideration text is there because we've been 
> struggling to understand whether, with the KEM specifications that 
> will be standardized by NIST, the KEM would be expected to output a 
> shared secret that can be used directly as a one-time-pad (i.e. the 
> bits of the shared secret are a random key). If I'm reading your email 
> properly, you're advocating that a KEM's output should be hashed 
> together with some protocol-level contextual values before it's used?

In
K := KDF(K* || H(c))

Regards,
Leonie

> The consensus at the LAMPS interim was to bring these discussions back 
> to RSA-KEM (5990). The KEM shared secret Z is not itself IID, so they 
> run it through a KDF (by itself) in Step 3 to be able to use it as a KEK.
> KEK = KDF (Z, kekLen)
> WK = Wrap (KEK, K)
> 
> 
> So we have two examples of compatible KEMs, and one that isn't 
> directly but could be made compatible. But we're not sufficiently 
> expert in KEMs to know if this applies only to some PQC KEMs, to all 
> PQC KEMs, or all KEMs present and future. Or, to your point, whether 
> this is actually how KEM outputs are intended to be used, or if you 
> need to hash them with protocol context values first. We believed, 
> from looking at the Kyber and SIKE construction that an extra KDF step 
> (and parameter) was unnecessary, but we're happy to add it if it 
> improves security or makes this mode more generally applicable to more KEM primitives.
> 
> ounsworth-pq-composite-encryption, in particular option 2 (encryption 
> and KEMs).
> 
> (e.g. the public
> key) in order to receive the shared secret. Thus, I would conclude 
> that these KEMs are not qualified.
> 
> If I use KEMs in a composite encryption mode, I certainly want them to 
> be CCA secure so I can use the public key multiple times. Otherwise it 
> won't make sense to put them in a certificate.
> 
> Comment: Using gpg4o v6.0.124.9651 - 
> https://urldefense.com/v3/__https://www.gpg4o.de/__;!!FJ-Y8qCqXTj2!IXB
> jLmZsx56eS923AqMx8DnfVF-JjqfE47JPJxm3e9u5b77DG6MGQAJq6ItjqqewGhTD$
> Charset: utf-8
> 
> Any email and files/attachments transmitted with it are confidential 
> and are intended solely for the use of the individual or entity to 
> whom they are addressed. If this message has been sent to you in 
> error, you must not copy, distribute or disclose of the information it 
> contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 16 Sep 2021 14:48:37 +0000

To flesh out the below idea, here is what the encryption/decryption procedure would look like:

Generation Procedure:

   1. If recipient public key is of type id-composite-or-key, determine the
      index of the last recipient public key to be encrypted for
        i_last := index of last Pi to be encrypted for
      Else,
        i_last = n
     Set K to a supported Key Derivation Function listed in the public key.  If no such Key Derivation Function in the list, return FAILURE

   2. To generate secret keys Sn, compute the following

      C := emptyOctetString
      for i := 1 to n

        a. If id-composite-or-key and Pi is to be skipped
          Ei := emptyOctetString
          continue to next i

        b. If Ai is a public key encryption scheme
            S := random_bits(SIZE)
            Ei = encrypt(S, Pi, Ai)
            C := C || S
          Else /* Ai is a key exchange method */,
            Ei, S := kem_generate(Pi, Ai)
            C := C || S

   3. Compute CEK := K( C, nonce )    /* The nonce is passed in by the caller */

   4. Output CEK and E1, E2, .., En

Decryption Procedure:
   1. C := emptyOctetString
       K := KDF selected in the ciphertext
        for i := 1 to n
          if Ei != emptyOctetString
            If Ai is a public key encryption scheme
              C := C || decrypt(Ei, SKi)
           Else
              C := C || kem_receive( Ei, Ski )

   3. Compute CEK := K( C, nonce )

   4. Output CEK

Obvious things to work out (assuming that you are willing to entertain such a change):

- I mention SIZE during the encryption process - what is that?

- I don't know if there is an existing IANA registry for KDFs that we could use - would we have to define it?

- I have heard of a complaint that if the KDF was based on a non-collision-resistant hash function, then (because we're using concatenation before the KDF) in some attack models, he could learn the initial byte or two of the next secret.  Is this an issue we should try to address?

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 16 Sep 2021 21:01:10 +0000

Hi Scott,

Just to take a step back here for context; to start this discussion, we submitted three different composite key establishment modes:
1. Only encryptions
2. One or more encryptions + zero or more KEMs
3. Any combination of encryptions, KEMs, KeyExs. This mode runs everything through a KDF as per SP 800-56Cr2.

The differences between 2 and 3 is that Mode 2:
* Allows you to input a pre-existing CEK rather than have one derived, and
* Does not need to specify a KDF in composite-encryption params.

If you're suggesting to engineer out both of these benefits, then maybe it's better to just use mode 3? :)

Consider the CMS use-case where you have a message. You envelope it with AES. Now you have an AES key that you need to encrypt a copy of for each of the recipients. Modes 1 and 2 are intended to implement CMS KeyTransRecipientInfo using only the asymmetric primitives in the recipient's composite public key, and XOR, and an RNG. No KDF needed; no block / stream cipher needed. Can add them if necessary, but let's make sure they're necessary.

Mode 3 does not implement KeyTransRecipientInfo because the CEK falls out of doing all the separate key establishments and hashing them all together.

There was good debate at the interim about what interfaces a PQ CMS actually needs to implement .. KeyTransRecipientInfo? KeyAgreeRecipientInfo? Or should we define a new KEMRecipientInfo and just implement that, in which case we could shorten this draft down to only Mode 3.
If we decide to implement Mode 3 as a KeyTransRecipientInfo or KeyAgreeRecipientInfo, then we would need to include a block / stream cipher inside the composite-encryption primitive. If we define a new KEMRecipientInfo then we could decide to include that block / stream cipher at the CMS layer.
Let's start by deciding what interfaces we're trying to implement.

PS. From Kris and Marku's messages it sounds like the "KEM MUST produce IID shared secret" is fulfilled by all PQC KEMs and not actually a problem in practice. If we're bashing at the restrictions on Mode 2, I would like to bash at the requirement to have at least one encryption, and engineer a way to make it work with only KEMs.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: September 16, 2021 8:58 AM
To: Ilari Liusvaara <[email-masked]>; Bruckert, Leonie <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [lamps] Which PQC KEMs can be used for composite encryption?

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!OB1peWGTjZaKFG0egYfcDknGBu2DIY1jRjK6AapXVE6XyM0urCN6I0a9AdeW3kTHPlPyBqiHyg$
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 17 Sep 2021 13:19:43 +0000

I'm sorry, I missed the context; I was responding to Ilari's comments.

That said, I would have to reiterate that your "Composite Key Transport using Encryption and KEM primitives" does have issues; it makes some assumptions on the KEMs, and while some KEMs will meet those assumptions, others won't.

Again, if you are doing a general construction, it would make more sense to go with a composite method that makes minimal assumptions on the primitives it relies on; the "composite key exchange" you have in section 4 comes considerably closer to that.

And, if you find the need to do key transport (or public key encryption in general) with the method of section 4, you can always use the "Integrated Encryption System" method - you have your composite key exchange generate a shared key, which you use as the key for a symmetric cipher to encrypt the message you're sending.  Yes, that does mean negotiating yet another primitive; however (IMHO) the conservative nature of the approach warrants it.

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Mike Ounsworth
Sent: Thursday, September 16, 2021 5:01 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]>; Ilari Liusvaara <[email-masked]>; Bruckert, Leonie <[email-masked]>
Cc: [email-masked]
Subject: Re: [lamps] Which PQC KEMs can be used for composite encryption?

Hi Scott,

Just to take a step back here for context; to start this discussion, we submitted three different composite key establishment modes:
1. Only encryptions
2. One or more encryptions + zero or more KEMs 3. Any combination of encryptions, KEMs, KeyExs. This mode runs everything through a KDF as per SP 800-56Cr2.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: September 16, 2021 8:58 AM
To: Ilari Liusvaara <[email-masked]>; Bruckert, Leonie <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [lamps] Which PQC KEMs can be used for composite encryption?

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm