Subject: [lamps] draft-ounsworth-pq-composite-encryption key combination

From: Florence D <[email-masked]>
Date: Tue, 15 Mar 2022 09:20:03 +0000

Hi,

I was reading draft-ounsworth-pq-composite-encryption in advance of the meeting next week and wanted to flag a potential issue with the constructions defined in section 2 "Composite Key Transport using Encryption primitives" and section 3 "Composite Key Transport using Encryption and KEM".  These are vulnerable to a chosen ciphertext attack which allows the attacker to recover the content encryption key with two calls to a decryption oracle.

Imagine the following for the encryption primitive case where n = 2:

   Input:

        Public Key = (P1, P2)

        CEK = Content Encryption Key

        S1 = Random secret value

   Output:

        (E1, E2) = (Enc1(P1, S1), Enc2(P2, S1 XOR CEK))

    The attacker calculates:

        E1' = Enc1(P1, 0)

        E2' = Enc2(P2, 0)

    And then calls the decryption oracle on (E1', E2) -> (0) XOR (S1 XOR CEK) and (E1, E2') -> (S1) XOR (0)

    The attacker can then xor the two values to recover the CEK.

A similar approach applies when Enc1 is a KEM.  In this case the attacker doesn't have direct control over the secret value so generates E1', S1' = Enc1(P1) and includes S1' in the final XOR.

draft-ietf-tls-hybrid-design [1] links to several papers which cover the challenges of combining multiple encryption schemes [2] (which includes the approach above in section 3.1), [3] and [4].  These papers all have suggestions for combining multiple encryption algorithms in ways which are IND-CCA secure, but they're considerably more complicated that the "natural" approach.  I suppose whether the more complicated approach is necessary depends on the use cases and whether a) security against a chosen ciphertext attack is required and b) if the composite key exchange approach is sufficient.  If the draft sticks with the current approach then I'd suggest that this issue is included in the security considerations.

It might also be worth noting that there's been a bit of discussion on the TLS mailing list about the pros and cons of using concatenation followed by a KDF for hybrid keys [5] and [6] (as in section 4 of this draft).

Flo

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

[2] Chosen-Ciphertext Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-30576-7_11.pdf

[3] On the Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-24632-9_26.pdf

[4] On Robust Combiners for Oblivious Transfer and Other Primitives: https://link.springer.com/content/pdf/10.1007%2F11426639_6.pdf

[5] https://mailarchive.ietf.org/arch/msg/tls/GenWgNbYhwkRWNzNvUHIwk1HfWw/

[6] https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/

Florence D

UK National Cyber Security Centre

[email-masked]<mailto:[email-masked]>

Pronouns: she/her

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright (c)

---

From: Mike Ounsworth <[email-masked]>
Date: Tue, 15 Mar 2022 21:43:48 +0000

Hello Florence.

Thank you for the review and the links, this is exactly what public review is for!

I will start by saying that none of the draft-ounsworth-pq-composite-* drafts are mature enough yet to present for working group adoption. We have spent the past few months working on the composite public keys draft - merging generic and explicit into a single mechanism, as well as better representing AND, OR, ANY, KofN modes in the public key. This is what I will be presenting at LAMPS next week. We are still tweaking so it's not up on Datatracker yet, but the working copy is here:

https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt

Once we have public keys on track for WG adoption, we think that composite encryption would be the next draft to put serious work into. Our current thinking is to present a composite KEM, following the pattern of RSA-KEM (RFC 5990) to fit within the CMS KEM object defined in draft-perret-prat-lamps-cms-pq-kem, and to use the NIST SP 800-56Cr2 KDF combiner similar to section 4 of our current composite-encryption draft. This will also need public scrutiny, and I agree that it would be great to get it aligned with the hybrid TLS work. As always, we welcome feedback and collaborations.

Aside about nomenclature: I really dislike the term "hybrid" here since it's very close to "hybrid encryption" which already has a meaning. The phrase "We're using a hybrid KEM within the S/MIME hybrid content encryption framework" is a bit confusing. I personally prefer "multi-key KEM" or "multi-algorithm KEM", of which "composite" is a specific multi-key scheme.

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm <[email-masked]> On Behalf Of Florence D
Sent: March 15, 2022 4:20 AM
To: [email-masked]
Subject: [EXTERNAL] [lamps] draft-ounsworth-pq-composite-encryption key combination

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,

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1' = Enc1(P1, 0)

        E2' = Enc2(P2, 0)

Flo

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/__;!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRvBh_Hpg$>

[2] Chosen-Ciphertext Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-30576-7_11.pdf<https://urldefense.com/v3/__https:/link.springer.com/content/pdf/10.1007*2F978-3-540-30576-7_11.pdf__;JQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xSLIrHmlg$>

[3] On the Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-24632-9_26.pdf<https://urldefense.com/v3/__https:/link.springer.com/content/pdf/10.1007*2F978-3-540-24632-9_26.pdf__;JQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRhN7UPbA$>

[4] On Robust Combiners for Oblivious Transfer and Other Primitives: https://link.springer.com/content/pdf/10.1007%2F11426639_6.pdf<https://urldefense.com/v3/__https:/link.springer.com/content/pdf/10.1007*2F11426639_6.pdf__;JQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTrtQIYcg$>

[5] https://mailarchive.ietf.org/arch/msg/tls/GenWgNbYhwkRWNzNvUHIwk1HfWw/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/tls/GenWgNbYhwkRWNzNvUHIwk1HfWw/__;!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTxBjWVPA$>

[6] https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/__;!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xQGBXeXXQ$>

Florence D

Pronouns: she/her

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]<mailto:[email-masked]>. All material is UK Crown Copyright (c)
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: Florence D <[email-masked]>
Date: Wed, 16 Mar 2022 17:21:57 +0000

Hi Mike,

Thanks very much for the information and the working copy of the composite public keys draft, I’m looking forward to seeing the presentation at LAMPS next week.  This might be a question for after the meeting, but I’d be interested in the use cases where the “K of N” mode is desired, as the implementation sounds like it could get complicated.

On the aside about nomenclature, I agree that the overloaded use of the word hybrid could be awkward.  Again, this is something on which it would be good to have an agreed approach across the WGs; I’m happy to use whatever language people find clearest, but it gets confusing if different WGs are using different terminology for the same or similar concepts.

Best,
Flo

From: Mike Ounsworth <Mike.Ounsworth=[email-masked]>
Sent: 15 March 2022 21:44
To: Florence D <[email-masked]>; [email-masked]
Subject: RE: draft-ounsworth-pq-composite-encryption key combination

You don't often get email from mike.ounsworth=[email-masked]. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
Hello Florence.

I will start by saying that none of the draft-ounsworth-pq-composite-* drafts are mature enough yet to present for working group adoption. We have spent the past few months working on the composite public keys draft – merging generic and explicit into a single mechanism, as well as better representing AND, OR, ANY, KofN modes in the public key. This is what I will be presenting at LAMPS next week. We are still tweaking so it’s not up on Datatracker yet, but the working copy is here:

https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEntrustCorporation%2Fdraft-ounsworth-pq-composite-keys%2Fblob%2Fmaster%2Fdraft-ounsworth-pq-composite-keys.txt&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=gUufNvwqsfdXk%2B9RlsZ%2FWbr1MR%2FFO9K8rOpYx%2BMmcVg%3D&reserved=0>

Aside about nomenclature: I really dislike the term “hybrid” here since it’s very close to “hybrid encryption” which already has a meaning. The phrase “We’re using a hybrid KEM within the S/MIME hybrid content encryption framework” is a bit confusing. I personally prefer “multi-key KEM” or “multi-algorithm KEM”, of which “composite” is a specific multi-key scheme.

---
Mike Ounsworth

Hi,

I was reading draft-ounsworth-pq-composite-encryption in advance of the meeting next week and wanted to flag a potential issue with the constructions defined in section 2 “Composite Key Transport using Encryption primitives” and section 3 “Composite Key Transport using Encryption and KEM”.  These are vulnerable to a chosen ciphertext attack which allows the attacker to recover the content encryption key with two calls to a decryption oracle.

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1’ = Enc1(P1, 0)

        E2’ = Enc2(P2, 0)

    And then calls the decryption oracle on (E1’, E2) -> (0) XOR (S1 XOR CEK) and (E1, E2’) -> (S1) XOR (0)

A similar approach applies when Enc1 is a KEM.  In this case the attacker doesn’t have direct control over the secret value so generates E1’, S1’ = Enc1(P1) and includes S1’ in the final XOR.

draft-ietf-tls-hybrid-design [1] links to several papers which cover the challenges of combining multiple encryption schemes [2] (which includes the approach above in section 3.1), [3] and [4].  These papers all have suggestions for combining multiple encryption algorithms in ways which are IND-CCA secure, but they’re considerably more complicated that the “natural” approach.  I suppose whether the more complicated approach is necessary depends on the use cases and whether a) security against a chosen ciphertext attack is required and b) if the composite key exchange approach is sufficient.  If the draft sticks with the current approach then I’d suggest that this issue is included in the security considerations.

It might also be worth noting that there’s been a bit of discussion on the TLS mailing list about the pros and cons of using concatenation followed by a KDF for hybrid keys [5] and [6] (as in section 4 of this draft).

Flo

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-hybrid-design%2F__%3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRvBh_Hpg%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s6M6zCpsgWLXdMlYXS6jbRynOZjciHMnYPvWMVNULXQ%3D&reserved=0>

[2] Chosen-Ciphertext Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-30576-7_11.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flink.springer.com%2Fcontent%2Fpdf%2F10.1007*2F978-3-540-30576-7_11.pdf__%3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xSLIrHmlg%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=J3MnTpIGUpXdFaD%2BHL1byAld8oBpt7Mxv0o2BMAKMiA%3D&reserved=0>

[3] On the Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-24632-9_26.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flink.springer.com%2Fcontent%2Fpdf%2F10.1007*2F978-3-540-24632-9_26.pdf__%3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRhN7UPbA%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=vQ3yGCpaIB5zLbBkz43W%2FAzVDleMf4s%2BEK25s60dj0o%3D&reserved=0>

[4] On Robust Combiners for Oblivious Transfer and Other Primitives: https://link.springer.com/content/pdf/10.1007%2F11426639_6.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flink.springer.com%2Fcontent%2Fpdf%2F10.1007*2F11426639_6.pdf__%3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTrtQIYcg%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=greI0PjGfjQ7O%2Fukx%2BqG0OujNN%2FxR5tuFoEgiqV0zF4%3D&reserved=0>

[5] https://mailarchive.ietf.org/arch/msg/tls/GenWgNbYhwkRWNzNvUHIwk1HfWw/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FGenWgNbYhwkRWNzNvUHIwk1HfWw%2F__%3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTxBjWVPA%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0FjJD9sgOkVpWj0SifFLoIk1XYPN1M3s5JKeVmU%2Brtw%3D&reserved=0>

[6] https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FF4SVeL2xbGPaPB2GW_GkBbD_a5M%2F__%3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xQGBXeXXQ%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cece886f02b054534eed108da06ccf041%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637829775591518176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Aurzn5hl96ptKKXPnuCQiKagY2qAuJFGi96E4TyW%2FDc%3D&reserved=0>

Florence D

Pronouns: she/her

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]<mailto:[email-masked]>. All material is UK Crown Copyright ©
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: Mike Ounsworth <[email-masked]>
Date: Wed, 16 Mar 2022 17:49:25 +0000

Hi Florence,

About “K of N” mode:
This was introduced when we merged with our co-authors from D-Trust in incorporated content from their Intelligent Composed Algorithms specification here:
https://eprint.iacr.org/2021/813.pdf
The motivating use-case for this is theirs, I’ll try to get a slide on that for LAMPS next week.

For signatures, I believe the “K of N” logic is not so bad: you make sure there’s at least k valid signatures on a document. For encryption, if it’s taken to mean that the encryptor uses all keys and the decryptor gets to choose k to decrypt with, then it’s hideously complicated, but if it means that the encryptor gets to choose k keys and all of them will be needed to decrypt, then I think the logic will be the same as an AND mode but with not all the keys. I expect there will be interesting debate when we get there!

---
Mike Ounsworth

From: Florence D <Florence.D=[email-masked]>
Sent: March 16, 2022 12:22 PM
To: Mike Ounsworth <[email-masked]>; [email-masked]
Subject: [EXTERNAL] RE: draft-ounsworth-pq-composite-encryption key combination

From: Mike Ounsworth <Mike.Ounsworth=[email-masked]<mailto:Mike.Ounsworth=[email-masked]>>
Sent: 15 March 2022 21:44
To: Florence D <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-ounsworth-pq-composite-encryption key combination

You don't often get email from mike.ounsworth=[email-masked]<mailto:mike.ounsworth=[email-masked]>. Learn why this is important<https://urldefense.com/v3/__http:/aka.ms/LearnAboutSenderIdentification__;!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQij_AB2v$>
Hello Florence.

https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2FEntrustCorporation*2Fdraft-ounsworth-pq-composite-keys*2Fblob*2Fmaster*2Fdraft-ounsworth-pq-composite-keys.txt&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=gUufNvwqsfdXk*2B9RlsZ*2FWbr1MR*2FFO9K8rOpYx*2BMmcVg*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQhw5N_Tg$>

---
Mike Ounsworth

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Florence D
Sent: March 15, 2022 4:20 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] [lamps] draft-ounsworth-pq-composite-encryption key combination

Hi,

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1’ = Enc1(P1, 0)

        E2’ = Enc2(P2, 0)

Flo

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-tls-hybrid-design*2F__*3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRvBh_Hpg*24&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=s6M6zCpsgWLXdMlYXS6jbRynOZjciHMnYPvWMVNULXQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQj0p07WC$>

[2] Chosen-Ciphertext Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-30576-7_11.pdf<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Flink.springer.com*2Fcontent*2Fpdf*2F10.1007*2F978-3-540-30576-7_11.pdf__*3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xSLIrHmlg*24&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=J3MnTpIGUpXdFaD*2BHL1byAld8oBpt7Mxv0o2BMAKMiA*3D&reserved=0__;JSUlJSUlJSUlJSolJSUlJSUlJSUlJSUlJSUl!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQvUB7SwQ$>

[3] On the Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-24632-9_26.pdf<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Flink.springer.com*2Fcontent*2Fpdf*2F10.1007*2F978-3-540-24632-9_26.pdf__*3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRhN7UPbA*24&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=vQ3yGCpaIB5zLbBkz43W*2FAzVDleMf4s*2BEK25s60dj0o*3D&reserved=0__;JSUlJSUlJSUlJSolJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQv7TiHIK$>

[4] On Robust Combiners for Oblivious Transfer and Other Primitives: https://link.springer.com/content/pdf/10.1007%2F11426639_6.pdf<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Flink.springer.com*2Fcontent*2Fpdf*2F10.1007*2F11426639_6.pdf__*3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTrtQIYcg*24&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=greI0PjGfjQ7O*2Fukx*2BqG0OujNN*2FxR5tuFoEgiqV0zF4*3D&reserved=0__;JSUlJSUlJSUlJSolJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQktH5r9O$>

[5] https://mailarchive.ietf.org/arch/msg/tls/GenWgNbYhwkRWNzNvUHIwk1HfWw/<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Ftls*2FGenWgNbYhwkRWNzNvUHIwk1HfWw*2F__*3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTxBjWVPA*24&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=0FjJD9sgOkVpWj0SifFLoIk1XYPN1M3s5JKeVmU*2Brtw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQggQYWjL$>

[6] https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/<https://urldefense.com/v3/__https:/eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fmailarchive.ietf.org*2Farch*2Fmsg*2Ftls*2FF4SVeL2xbGPaPB2GW_GkBbD_a5M*2F__*3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xQGBXeXXQ*24&data=04*7C01*7CFlorence.D*40ncsc.gov.uk*7Cece886f02b054534eed108da06ccf041*7C14aa5744ece1474ea2d734f46dda64a1*7C0*7C0*7C637829775591518176*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=Aurzn5hl96ptKKXPnuCQiKagY2qAuJFGi96E4TyW*2FDc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!FJ-Y8qCqXTj2!MO91mMSfh1b0TQuJ9CjXxsmLJVaDC74D9YT3T_aV4WxLk7yKdhI89aHu_PTLQuy8BbBR$>

Florence D

Pronouns: she/her

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 17 Mar 2022 18:36:07 +0000

The terminology discussion is interesting.  I share your concern that "hybrid" isn't a great name.  It would be nice to get consensus on defined terms for talking about this sort of thing sooner rather than later.

I'm already having to translate in my head between several different sets of terms for this in several different groups.  I know that I'm likely to have to continue doing that forever (as is normal when dealing with multiple industry groups), but I would love it if we could agree on some reasonable definitions for terms here, so I can start promoting their use...

-Tim

From: Spasm <[email-masked]> On Behalf Of Mike Ounsworth
Sent: Tuesday, March 15, 2022 5:44 PM
To: Florence D <Florence.D=[email-masked]>; [email-masked]
Subject: Re: [lamps] draft-ounsworth-pq-composite-encryption key combination

Hello Florence.

---
Mike Ounsworth

Hi,

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1' = Enc1(P1, 0)

        E2' = Enc2(P2, 0)

Flo

Florence D

Pronouns: she/her

---

From: Mike Ounsworth <[email-masked]>
Date: Thu, 17 Mar 2022 19:49:26 +0000

> but I would love it if we could agree on some reasonable definitions for terms here, so I can start promoting their use…

Want to start a draft? 😉

---
Mike Ounsworth

From: Tim Hollebeek <tim.hollebeek=[email-masked]>
Sent: March 17, 2022 1:36 PM
To: Mike Ounsworth <[email-masked]>; Florence D <[email-masked]>; [email-masked]
Subject: [EXTERNAL] RE: draft-ounsworth-pq-composite-encryption key combination

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
The terminology discussion is interesting.  I share your concern that “hybrid” isn’t a great name.  It would be nice to get consensus on defined terms for talking about this sort of thing sooner rather than later.

I’m already having to translate in my head between several different sets of terms for this in several different groups.  I know that I’m likely to have to continue doing that forever (as is normal when dealing with multiple industry groups), but I would love it if we could agree on some reasonable definitions for terms here, so I can start promoting their use…

-Tim

From: Spasm <[email-masked]<mailto:[email-masked]>> On Behalf Of Mike Ounsworth
Sent: Tuesday, March 15, 2022 5:44 PM
To: Florence D <Florence.D=[email-masked]<mailto:Florence.D=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [lamps] draft-ounsworth-pq-composite-encryption key combination

Hello Florence.

https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt<https://urldefense.com/v3/__https:/github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt__;!!FJ-Y8qCqXTj2!PjlyZToh8nLZOv0GtaN3_kDRVjIAVSuxXla_AzVMP-qbLoyCmvfgOSTwnCc94FPm4qol$>

---
Mike Ounsworth

Hi,

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1’ = Enc1(P1, 0)

        E2’ = Enc2(P2, 0)

Flo

Florence D

Pronouns: she/her

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 17 Mar 2022 19:51:05 +0000

Willing to collaborate on one.  My time constraints are pretty fierce right now.

-Tim

From: Mike Ounsworth <Mike.Ounsworth=[email-masked]>
Sent: Thursday, March 17, 2022 3:49 PM
To: Tim Hollebeek <[email-masked]>; Florence D <[email-masked]>; [email-masked]
Subject: RE: draft-ounsworth-pq-composite-encryption key combination

Want to start a draft? 😉

---
Mike Ounsworth

From: Tim Hollebeek <tim.hollebeek=[email-masked]<mailto:tim.hollebeek=[email-masked]>>
Sent: March 17, 2022 1:36 PM
To: Mike Ounsworth <[email-masked]<mailto:[email-masked]>>; Florence D <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] RE: draft-ounsworth-pq-composite-encryption key combination

-Tim

Hello Florence.

---
Mike Ounsworth

Hi,

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1’ = Enc1(P1, 0)

        E2’ = Enc2(P2, 0)

Flo

Florence D

Pronouns: she/her

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Mar 2022 19:26:40 -0400

Tim Hollebeek <tim.hollebeek=[email-masked]> wrote:
    > The terminology discussion is interesting.  I share your concern that
    > "hybrid" isn't a great name.  It would be nice to get consensus on
    > defined terms for talking about this sort of thing sooner rather than
    > later.

We need to just pick two or three arbitrary names.

Much like the _Copenhagen_ interpretation for quantum mechanics is just the
name of the place where the conference occured.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Florence D <[email-masked]>
Date: Fri, 18 Mar 2022 09:21:37 +0000

> Want to start a draft?

Being relatively new to the IETF I don’t know if a draft would be helpful here, but if it is then I’d be keen to contribute or review.  We’re going to be working on PQ for years, so getting the language right (or at least consistent) near the beginning would be great.

Flo

From: Tim Hollebeek <[email-masked]>
Sent: 17 March 2022 19:51
To: Mike Ounsworth <Mike.Ounsworth=[email-masked]>; Florence D <[email-masked]>; [email-masked]
Subject: RE: draft-ounsworth-pq-composite-encryption key combination

You don't often get email from [email-masked]. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification>
Willing to collaborate on one.  My time constraints are pretty fierce right now.

-Tim

Want to start a draft? 😉

---
Mike Ounsworth

-Tim

Hello Florence.

https://github.com/EntrustCorporation/draft-ounsworth-pq-composite-keys/blob/master/draft-ounsworth-pq-composite-keys.txt<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2FEntrustCorporation%2Fdraft-ounsworth-pq-composite-keys%2Fblob%2Fmaster%2Fdraft-ounsworth-pq-composite-keys.txt__%3B!!FJ-Y8qCqXTj2!PjlyZToh8nLZOv0GtaN3_kDRVjIAVSuxXla_AzVMP-qbLoyCmvfgOSTwnCc94FPm4qol%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843682935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=oFTJBrqveDdCypaNcrM0nWbMiC7dnmURhs76UOJJ8TM%3D&reserved=0>

---
Mike Ounsworth

Hi,

   Input:

        Public Key = (P1, P2)

        S1 = Random secret value

   Output:

    The attacker calculates:

        E1’ = Enc1(P1, 0)

        E2’ = Enc2(P2, 0)

Flo

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-hybrid-design%2F__%3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRvBh_Hpg%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843682935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=yQKJEL8mPO5GmTtTHoemLOhqzwFhoxLIFLwc5LiScWo%3D&reserved=0>

[2] Chosen-Ciphertext Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-30576-7_11.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flink.springer.com%2Fcontent%2Fpdf%2F10.1007*2F978-3-540-30576-7_11.pdf__%3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xSLIrHmlg%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843682935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=cJcEyXFD%2BEm2wu4FA5uqayBPNuLzIFKs7vhD5lR22vM%3D&reserved=0>

[3] On the Security of Multiple Encryption: https://link.springer.com/content/pdf/10.1007%2F978-3-540-24632-9_26.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flink.springer.com%2Fcontent%2Fpdf%2F10.1007*2F978-3-540-24632-9_26.pdf__%3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xRhN7UPbA%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843682935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2F%2B9Vdsjf5SX%2BiPH%2BRzG7pGZPfVz4ULFC%2FE0lOz0ZQCY%3D&reserved=0>

[4] On Robust Combiners for Oblivious Transfer and Other Primitives: https://link.springer.com/content/pdf/10.1007%2F11426639_6.pdf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Flink.springer.com%2Fcontent%2Fpdf%2F10.1007*2F11426639_6.pdf__%3BJQ!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTrtQIYcg%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843682935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s51naFMUbysJkgMRMJJmc2gC9YXgNVakOR1sMbn5Mo0%3D&reserved=0>

[5] https://mailarchive.ietf.org/arch/msg/tls/GenWgNbYhwkRWNzNvUHIwk1HfWw/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FGenWgNbYhwkRWNzNvUHIwk1HfWw%2F__%3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xTxBjWVPA%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843838877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=8%2BjhcPGtxg8RyKvvyo2rI%2F7eGu5eA39XjIIobkaou4s%3D&reserved=0>

[6] https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FF4SVeL2xbGPaPB2GW_GkBbD_a5M%2F__%3B!!FJ-Y8qCqXTj2!LnAgn2_1L4lpwZ2mSXrtf7GgOaFAV8JNEQEusYIaTKsvLdEaLtSq6RWbrlno9DJ80xQGBXeXXQ%24&data=04%7C01%7CFlorence.D%40ncsc.gov.uk%7Cb5d58a7512974c0751a408da084f7b74%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C637831434843838877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=dSoM3EhJm41NCXMyR0Mg3MlKJs03EzvAl8y8kArALrw%3D&reserved=0>

Florence D

Pronouns: she/her

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Mar 2022 13:35:00 +0200

On Tue, Mar 15, 2022 at 09:20:03AM +0000, Florence D wrote:
> 
> draft-ietf-tls-hybrid-design [1] links to several papers which cover
> the challenges of combining multiple encryption schemes [2] (which
> includes the approach above in section 3.1), [3] and [4].  These
> papers all have suggestions for combining multiple encryption
> algorithms in ways which are IND-CCA secure, but they're considerably
> more complicated that the "natural" approach.  I suppose whether the
> more complicated approach is necessary depends on the use cases and
> whether a) security against a chosen ciphertext attack is required
> and b) if the composite key exchange approach is sufficient.  If the
> draft sticks with the current approach then I'd suggest that this
> issue is included in the security considerations.

And there is further complication that not all KEMs have the same output
length. In NISTPQC, usually all secret outputs are 256 bits, but there
are some variants with 128-bit or 192-bit outputs.

For the n-of-n (AND) case, would just concatenating constant-length
outputs be sufficient? Probably needs assumption of strong hash, but
assuming that might be feasible.

For the 1-of-n (OR) and k-of-n cases, those are nontrivial to do without
making asymmetric encryption out of the KEM.

Oh, and one thing to be careful about with those "robust combiners" is
that there might be assumption that all component KEMs are IND-CCA, but
I am not sure if DH-based KEMs are actually IND-CCA. And breaking
assumptions can lead to big problems.

> It might also be worth noting that there's been a bit of discussion
> on the TLS mailing list about the pros and cons of using
> concatenation followed by a KDF for hybrid keys [5] and [6] (as in
> section 4 of this draft).

>From what I understand, for concatenation is only problematic if
both of the following are true:

- The KDF is not a strong hash.
- The KEM has variable-length output.

And in context of TLS 1.3, breaking either is a big problem:

- First failing turns to break TLS 1.3 security outright.
- Variable-length KEM outputs are a Bad Idea (RACCOON anyone?)

> [6] https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_GkBbD_a5M/

-Ilari

---

From: Mike Ounsworth <[email-masked]>
Date: Fri, 18 Mar 2022 19:54:07 +0000

Thank you Ilari.

I think we are on the same page, but to be explicit, we are working in the scope of CMS content encryption (aka RFC 5652 EnvelopedData), and the composite-kem draft that we have not publish yet will follow the model of RFC 5990 RSA-KEM, both of which are making asymmetric encryption out of the KEM. For the combiner, we are proposing to follow the advice of NIST SP 800-56Cr2 in the "hybrid shared secret" mode where Z' = Z || T, which is only a trivial change to the RFC 5990 model. We are assuming this is ok to extend to three or more inputs; Z' = Z1 || Z2 || Z3 ... So you do your key exchange / key transport / key encapsulation on each component algorithm, then you roll them all together into a master shared secret via KDF( Z' ) = KDF( Z1 || Z2 || Z3 ...).

I believe that completely avoids the issue of your component algs (keyex / key trans / kem) having different output lengths.

I believe that completely avoids the issue of your component algs (keyex / key trans / kem) not having "whitened" outputs (aka "uniformly distributed bits").

I agree with your point about component algorithms not being IND-CCA. This would be a good point for CFRG to help in specifying which combinations of algorithms are allowed. For the time-being, we are just trying to define the multi-key / composite / hybrid structures and processes in an algorithm-agnostic way. So to me, this is more of a Security Consideration -- "be careful what algs you use this with" -- rather than something to be addressed structurally, but I'm curious to hear discussion.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Ilari Liusvaara
Sent: March 18, 2022 6:35 AM
To: [email-masked]
Subject: [EXTERNAL] Re: [lamps] draft-ounsworth-pq-composite-encryption key combination

______________________________________________________________________
On Tue, Mar 15, 2022 at 09:20:03AM +0000, Florence D wrote:
> whether a) security against a chosen ciphertext attack is required and
> b) if the composite key exchange approach is sufficient.  If the draft
> sticks with the current approach then I'd suggest that this issue is
> included in the security considerations.

And there is further complication that not all KEMs have the same output length. In NISTPQC, usually all secret outputs are 256 bits, but there are some variants with 128-bit or 192-bit outputs.

For the n-of-n (AND) case, would just concatenating constant-length outputs be sufficient? Probably needs assumption of strong hash, but assuming that might be feasible.

For the 1-of-n (OR) and k-of-n cases, those are nontrivial to do without making asymmetric encryption out of the KEM.

Oh, and one thing to be careful about with those "robust combiners" is that there might be assumption that all component KEMs are IND-CCA, but I am not sure if DH-based KEMs are actually IND-CCA. And breaking assumptions can lead to big problems.

> It might also be worth noting that there's been a bit of discussion on
> the TLS mailing list about the pros and cons of using concatenation
> followed by a KDF for hybrid keys [5] and [6] (as in section 4 of this
> draft).

> [1]
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> f-tls-hybrid-design/__;!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly6YdaFYlffTOd
> uDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5LRRMLNPQ$
> [2] Chosen-Ciphertext Security of Multiple Encryption:
> https://urldefense.com/v3/__https://link.springer.com/content/pdf/10.1
> 007*2F978-3-540-30576-7_11.pdf__;JQ!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly
> 6YdaFYlffTOduDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5K-u9k9Yg$
> [3] On the Security of Multiple Encryption:
> https://urldefense.com/v3/__https://link.springer.com/content/pdf/10.1
> 007*2F978-3-540-24632-9_26.pdf__;JQ!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly
> 6YdaFYlffTOduDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5JmZ84P4w$
> [4] On Robust Combiners for Oblivious Transfer and Other Primitives:
> https://urldefense.com/v3/__https://link.springer.com/content/pdf/10.1
> 007*2F11426639_6.pdf__;JQ!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly6YdaFYlffT
> OduDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5LuGoPc_Q$
> [5]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/
> GenWgNbYhwkRWNzNvUHIwk1HfWw/__;!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly6Yda
> FYlffTOduDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5KTMMNPHg$
> [6]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/
> F4SVeL2xbGPaPB2GW_GkBbD_a5M/__;!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly6Yda
> FYlffTOduDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5IQlyglSw$

-Ilari

_______________________________________________
Spasm mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!Iq-nj6pqa35h5b9uQ_Ly6YdaFYlffTOduDJkesI9Qkk_8SYE8-U4rbfdBkdvmf8dN5IGzj4b1g$
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.