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

[Mike Ounsworth <[e-mail]>]

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 <[e-mail]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: September 16, 2021 8:58 AM
To: Ilari Liusvaara <[e-mail]>; Bruckert, Leonie <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [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.

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

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?

_______________________________________________
Spasm mailing list
[e-mail]
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.