Subject: [Cfrg] Multi-recipient public key authenticated encryption

From: Neil Madden <[email-masked]>
Date: Mon, 27 Apr 2020 15:12:07 +0100

Hi all,

I am working on an enhancement to the JOSE standards and would like feedback from members of CFRG about solutions to a particular issue if any of you have time.

In JOSE currently if you wish to create a message that has both confidentiality and sender authentication using public key cryptography then the only option is to both sign and then encrypt the message. This is expensive because it involves multiple passes over the message and results in a very bulky nested message structure with two layers of base64-encoding.

Given that many uses of this sign-then-encrypt pattern do not require the strong security properties of signatures, I have proposed [1] a public key authenticated encryption mode based on NIST’s one-pass unified model from SP 800-56A. This avoids the nested structure and means that you don’t need multiple cryptographic primitives. The proposed algorithm uses two ECDH key agreements: one between the sender’s ephemeral private key and the recipient’s long-term public key; and a second between the two parties’ long term keys. The two shared secrets are concatenated and passed through a KDF along with some context arguments. For a single recipient this achieves sender authentication (subject to replay), and the single recipient case is what I am primarily concerned about.

(If you squint this is also roughly similar to the Noise framework “K” one-way pattern, but my hands are waving quite a lot here).

To support multiple recipients I copied the existing pattern used in JOSE’s ECDH-ES+A256KW algorithm family in which the message is encrypted using a random Content Encryption Key (CEK) and then the CEK is encrypted for each recipient using AES-KeyWrap with the ECDH-derived key. As I then mention in the security considerations this leads to any recipient being able to produce a forgery using that CEK and claim it came from the original sender:

   When Key Agreement with Key Wrapping is used, with the same Content
   Encryption Key (CEK) reused for multiple recipients, any of those
   recipients can produce a new message that appears to come from the
   original sender.  The new message will be indistinguishable from a
   genuine message from the original sender to any of the other
   participants.  To avoid this attack, the content SHOULD be encrypted
   separately to each recipient with a unique CEK or a nested signature
   over the content SHOULD be used.

Because I am primarily interested in single-recipient use cases, this seemed like an acceptable trade-off. However, I have since been contacted by people who would like to use this draft for multi-recipient messages and would not like to fall back on a nested signature structure.

An initial proposal was to solve this by simply including the MAC tag from the content encryption in either the per-recipient payload (encrypted using AES-KeyWrap) or as an additional context field to the KDF. But the MAC is computed using the CEK that is known to all recipients, so for this to be secure would require second preimage resistance of the MAC with a known key, which cannot be guaranteed for JOSE because it supports content encryption using AES-GCM for which second preimages can be trivially computed if you know the key.

Assuming that a per-recipient MAC is too much overhead, an alternative would be to include a collision-resistant hash of entire ciphertext (and IV and associated data) in the KDF. This is unfortunate as it requires another pass over the entire message when we’ve already encrypted and MACed, but it appears to be a solution and at least is no more inefficient than the original signed-then-encrypted approach which also needs to hash the entire message.

So two questions:

1. Is including a hash (e.g., SHA-512) of the ciphertext (assuming symmetric AE) in the per-recipient KDF calculation sufficient to prevent forgeries in the multi-recipient setting?

2. Are there more efficient alternatives that don’t assume 2nd preimage resistance of the underlying symmetric MAC?

[1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 <https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03>

Kind regards,

Neil Madden

---

From: Paul Grubbs <[email-masked]>
Date: Mon, 27 Apr 2020 11:10:27 -0400

This sounds like a really interesting question, but I'm having trouble
understanding your proposed scheme - can you give a bit more detail?

I also don't quite understand the threat model. Are you trying to prevent a
malicious receiver from "forging" a new payload that looks like it came
from the sender?

On Mon, Apr 27, 2020 at 10:12 AM Neil Madden <[email-masked]>
wrote:

> Hi all,
>
> I am working on an enhancement to the JOSE standards and would like
> feedback from members of CFRG about solutions to a particular issue if any
> of you have time.
>
> In JOSE currently if you wish to create a message that has both
> confidentiality and sender authentication using public key cryptography
> then the only option is to both sign and then encrypt the message. This is
> expensive because it involves multiple passes over the message and results
> in a very bulky nested message structure with two layers of base64-encoding.
>
> Given that many uses of this sign-then-encrypt pattern do not require the
> strong security properties of signatures, I have proposed [1] a public key
> authenticated encryption mode based on NIST’s one-pass unified model from
> SP 800-56A. This avoids the nested structure and means that you don’t need
> multiple cryptographic primitives. The proposed algorithm uses two ECDH key
> agreements: one between the sender’s ephemeral private key and the
> recipient’s long-term public key; and a second between the two parties’
> long term keys. The two shared secrets are concatenated and passed through
> a KDF along with some context arguments. For a single recipient this
> achieves sender authentication (subject to replay), and the single
> recipient case is what I am primarily concerned about.
>
> (If you squint this is also roughly similar to the Noise framework “K”
> one-way pattern, but my hands are waving quite a lot here).
>
> To support multiple recipients I copied the existing pattern used in
> JOSE’s ECDH-ES+A256KW algorithm family in which the message is encrypted
> using a random Content Encryption Key (CEK) and then the CEK is encrypted
> for each recipient using AES-KeyWrap with the ECDH-derived key. As I then
> mention in the security considerations this leads to any recipient being
> able to produce a forgery using that CEK and claim it came from the
> original sender:
>
> Because I am primarily interested in single-recipient use cases, this
> seemed like an acceptable trade-off. However, I have since been contacted
> by people who would like to use this draft for multi-recipient messages and
> would not like to fall back on a nested signature structure.
>
> An initial proposal was to solve this by simply including the MAC tag from
> the content encryption in either the per-recipient payload (encrypted using
> AES-KeyWrap) or as an additional context field to the KDF. But the MAC is
> computed using the CEK that is known to all recipients, so for this to be
> secure would require second preimage resistance of the MAC with a known
> key, which cannot be guaranteed for JOSE because it supports content
> encryption using AES-GCM for which second preimages can be trivially
> computed if you know the key.
>
> Assuming that a per-recipient MAC is too much overhead, an alternative
> would be to include a collision-resistant hash of entire ciphertext (and IV
> and associated data) in the KDF. This is unfortunate as it requires another
> pass over the entire message when we’ve already encrypted and MACed, but it
> appears to be a solution and at least is no more inefficient than the
> original signed-then-encrypted approach which also needs to hash the entire
> message.
>
> So two questions:
>
> 1. Is including a hash (e.g., SHA-512) of the ciphertext (assuming
> symmetric AE) in the per-recipient KDF calculation sufficient to prevent
> forgeries in the multi-recipient setting?
>
> 2. Are there more efficient alternatives that don’t assume 2nd preimage
> resistance of the underlying symmetric MAC?
>
> [1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03
>
> Kind regards,
>
> Neil Madden
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Dan Brown <[email-masked]>
Date: Mon, 27 Apr 2020 15:19:43 +0000

Hi Neil,

I too have encountered this interesting and well-known (perhaps not widely-known) problem.

See https://eprint.iacr.org/2005/056.pdf. (Section 5).

See https://tools.ietf.org/html/rfc3278#section-4.1.2 the very short “note”.

I forget the details of the various claimed past solutions, but will try to remember, maybe in a couple weeks.  Meanwhile, since the problem is fresh in your mind, and you might try to make sense the couple of old suggestions above, though I expect your knowledge has already advance past this old stuff.   

Best regards,

Dan

From: Cfrg <[email-masked]> On Behalf Of Neil Madden
Sent: Monday, April 27, 2020 10:12 AM
To: CFRG <[email-masked]>
Subject: [Cfrg] Multi-recipient public key authenticated encryption

Hi all,

So two questions:

[1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmadden-2Djose-2Decdh-2D1pu-2D03&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=pABr2aBl1c_ofW8vypgq6rz4tGVZWkxu0IU_RSNb_L4&s=E_agQvNgeBlLsyPF6xyJ1TFQLBAJsGTY1FJf7EK3iqs&e=> 

Kind regards,

Neil Madden

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Neil Madden <[email-masked]>
Date: Mon, 27 Apr 2020 16:53:43 +0100

The details of the original proposed scheme are in the linked draft or are in NIST SP 800-56A. To summarise, if Alice wants to encrypt a message and send it to both Bob and Charlie she carries out the following steps (with some minor details of syntax elided):

1. Generate a random CEK and use it to encrypt the message content using some symmetric AEAD scheme producing authenticated ciphertext, C.
2. kek_bob = KDF(ECDH(ephemeral_private, bob_public) || ECDH(alice_private, bob_public) || context_bob)
3. kek_charlie = KDF(ECDH(ephemeral_private, charlie_public) || ECDH(alice_private, charlie_public) || context_charlie)
4. bob_box = AES-KW(kek_bob, CEK)
5. charlie_box = AES-KW(kek_charlie, CEK)
6. Send bob_box || charlie_box || ephemeral_public || C

Here the context arguments are typically the public keys involved and any additional identifiers for the parties involved. The new proposal is to also mix in SHA-512(C) into this KDF calculation as additional context.

The threat model here is that Alice sends a message to Bob and Charlie stating that Bob is in charge while she is on holiday. Charlie uses the shared CEK to create a new message saying “Oops, I meant that Charlie is in charge.” and sends that to Bob with the original encrypted keys (i.e., Charlie just replaces C). This new message from Charlie validates as if it came from Alice. I’d like to stop this kind of attack.

My assertion is that if you mix SHA-512(C) into the KDF calculation then Charlie needs to find a 2nd preimage of SHA-512 to pull off this attack. (I’m using SHA-512 as an example, actually JOSE already uses SHA-256 in its KDF so I’ll probably use that).

— Neil

> On 27 Apr 2020, at 16:10, Paul Grubbs <[email-masked]> wrote:
> 
> This sounds like a really interesting question, but I'm having trouble understanding your proposed scheme - can you give a bit more detail? 
> 
> I also don't quite understand the threat model. Are you trying to prevent a malicious receiver from "forging" a new payload that looks like it came from the sender?
> 
> On Mon, Apr 27, 2020 at 10:12 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>

---

From: Dan Brown <[email-masked]>
Date: Mon, 27 Apr 2020 16:00:28 +0000

Hi Neil,

I recall that “unified model” is well-known to lack some security property. Maybe, key-compromise impersonation (KCI)?

If Eve has Bob’s private key, can Eve impersonate Alice?

E.g. replace ECDH(alice_private, bob_public) by ECDH(bob_private, alice_public)?

Dan

From: Cfrg <[email-masked]> On Behalf Of Neil Madden
Sent: Monday, April 27, 2020 11:54 AM
To: Paul Grubbs <[email-masked]>
Cc: CFRG <[email-masked]>
Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption

— Neil

On 27 Apr 2020, at 16:10, Paul Grubbs <[email-masked] <mailto:[email-masked]> > wrote:

On Mon, Apr 27, 2020 at 10:12 AM Neil Madden <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

So two questions:

[1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmadden-2Djose-2Decdh-2D1pu-2D03&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=KlOwyf9hUXlVGjlgt8Wi940vBk4gshSudWFblTPOqqw&s=hl600UzfUwE0mwdBn12J1fBTXatCOOKthaRGKw9n6ZM&e=> 

Kind regards,

Neil Madden

_______________________________________________
Cfrg mailing list
[email-masked] <mailto:[email-masked]> 
https://www.irtf.org/mailman/listinfo/cfrg <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=KlOwyf9hUXlVGjlgt8Wi940vBk4gshSudWFblTPOqqw&s=Zsd48TBtVxnczibcn8zmbWpsdpRyprK6NbobiMEqaec&e=>

---

From: Neil Madden <[email-masked]>
Date: Mon, 27 Apr 2020 17:12:01 +0100

Yes, this is also discussed in the security considerations in section 4 of the draft.

I’m not aware of a solution to KCI in a single message without using signatures, but would be interested if there is anything out there.

The first version of the draft suggested how a two-message interactive handshake can be built from the basic ECDH-1PU construct that is roughly similar to the Noise KK two-way handshake pattern and would also prevent KCI. I was encouraged to drop that part as liable to corrupt the youth.

PS - thanks for the two references in the previous message, they are very useful and describe exactly the same problem.

— Neil

> On 27 Apr 2020, at 17:00, Dan Brown <[email-masked]> wrote:
> 
> Hi Neil,
> On 27 Apr 2020, at 16:10, Paul Grubbs <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Dan Brown <[email-masked]>
Date: Mon, 27 Apr 2020 16:37:48 +0000

Hi Neil,

My bad.  On KCI, I think you are right.  Oops, I forgot this, sorry!

If Alice wishes to deny sending the message, one way is to have Bob equally able to generate it.  But this exposes Bob to KCI.  

Maybe the state-of-the-art has a better way to solve this.

Dan

From: Neil Madden <[email-masked]> 
Sent: Monday, April 27, 2020 12:12 PM
To: Dan Brown <[email-masked]>
Cc: Paul Grubbs <[email-masked]>; CFRG <[email-masked]>
Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption

— Neil

On 27 Apr 2020, at 17:00, Dan Brown <[email-masked] <mailto:[email-masked]> > wrote:

Hi Neil,

Dan

From: Cfrg <[email-masked] <mailto:[email-masked]> > On Behalf Of Neil Madden
Sent: Monday, April 27, 2020 11:54 AM
To: Paul Grubbs <[email-masked] <mailto:[email-masked]> >
Cc: CFRG <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption

— Neil

On 27 Apr 2020, at 16:10, Paul Grubbs < <mailto:[email-masked]> [email-masked]> wrote:

On Mon, Apr 27, 2020 at 10:12 AM Neil Madden < <mailto:[email-masked]> [email-masked]> wrote:

Hi all,

So two questions:

[1]:  <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmadden-2Djose-2Decdh-2D1pu-2D03&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=KlOwyf9hUXlVGjlgt8Wi940vBk4gshSudWFblTPOqqw&s=hl600UzfUwE0mwdBn12J1fBTXatCOOKthaRGKw9n6ZM&e=> https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03

Kind regards,

Neil Madden

_______________________________________________
Cfrg mailing list
 <mailto:[email-masked]> [email-masked]
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_cfrg&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=KlOwyf9hUXlVGjlgt8Wi940vBk4gshSudWFblTPOqqw&s=Zsd48TBtVxnczibcn8zmbWpsdpRyprK6NbobiMEqaec&e=> https://www.irtf.org/mailman/listinfo/cfrg

  _____

---

From: Neil Madden <[email-masked]>
Date: Tue, 28 Apr 2020 13:30:07 +0100

Thanks, section 5 of the eprint is very useful. In that you discuss the solution of including the MAC tag in the KDF and you say that this requires collision resistance of the MAC, where I had previously assumed only 2nd preimage resistance would be enough. As I understand it, the potential attack is that if Charlie has access to an Alice-oracle by which he can get Alice to authenticate arbitrary messages to himself and Bob then he can use this to perform a collision search to find two messages with the same MAC tag (if the MAC is not collision resistant).

I think this active attack would also apply to my proposed solution using a hash of the authenticated ciphertext as input to the KDF. So my assertion that 2nd preimage is enough is only valid for passive attacks, and full collision resistance would be needed in general. That also means that if I do pick SHA-256 to be consistent with existing use in JOSE then the security against such attacks would be limited to ~128 bit level. Perhaps that’s an incentive for me to also change the KDF in the scheme from JOSE’s existing Concat-KDF to HKDF with SHA-512.

I think the same attack would also apply to saltpack [1], if I understand correctly? In saltpack a per-recipient MAC is calculated over a SHA-512 of the ciphertext.

[1] https://saltpack.org/encryption-format-v2 <https://saltpack.org/encryption-format-v2> (scroll down to Payload Packets)

Best,

Neil

> On 27 Apr 2020, at 16:19, Dan Brown <[email-masked]> wrote:
> 
> Hi Neil,
> See https://eprint.iacr.org/2005/056.pdf <https://eprint.iacr.org/2005/056.pdf>. (Section 5).
> See https://tools.ietf.org/html/rfc3278#section-4.1.2 <https://tools.ietf.org/html/rfc3278#section-4.1.2> the very short “note”.
>

---

From: Paul Grubbs <[email-masked]>
Date: Tue, 28 Apr 2020 11:14:37 -0400

I think you can get away without the additional hash of the ciphertext
entirely if you use a compactly committing AEAD (ccAE) scheme [1]. A ccAE
has a two-part ciphertext C = (C1, C2) with the property that C2 is a
binding commitment to the plaintext and key. At least intuitively, then,
using C2 in the KDF prevents a receiver from modifying the message. (This
is morally similar to including the MAC tag in the KDF, as suggested, but
sidesteps questions about MAC security and may be faster if optimal-rate
schemes like HFC [2] are used.) I haven't analyzed this construction
formally, though, so take this advice with a bit of salt.

[1] https://eprint.iacr.org/2017/664
[2] https://eprint.iacr.org/2019/016.pdf

On Tue, Apr 28, 2020 at 8:30 AM Neil Madden <[email-masked]> wrote:

> Thanks, section 5 of the eprint is very useful. In that you discuss the
> solution of including the MAC tag in the KDF and you say that this requires
> collision resistance of the MAC, where I had previously assumed only 2nd
> preimage resistance would be enough. As I understand it, the potential
> attack is that if Charlie has access to an Alice-oracle by which he can get
> Alice to authenticate arbitrary messages to himself and Bob then he can use
> this to perform a collision search to find two messages with the same MAC
> tag (if the MAC is not collision resistant).
>
> I think this active attack would also apply to my proposed solution using
> a hash of the authenticated ciphertext as input to the KDF. So my assertion
> that 2nd preimage is enough is only valid for passive attacks, and full
> collision resistance would be needed in general. That also means that if I
> do pick SHA-256 to be consistent with existing use in JOSE then the
> security against such attacks would be limited to ~128 bit level. Perhaps
> that’s an incentive for me to also change the KDF in the scheme from JOSE’s
> existing Concat-KDF to HKDF with SHA-512.
>
> I think the same attack would also apply to saltpack [1], if I understand
> correctly? In saltpack a per-recipient MAC is calculated over a SHA-512 of
> the ciphertext.
>
> [1] https://saltpack.org/encryption-format-v2 (scroll down to Payload
> Packets)
>
> Best,
>
> Neil
>
> I forget the details of the various claimed past solutions, but will try
> to remember, maybe in a couple weeks.  Meanwhile, since the problem is
> fresh in your mind, and you might try to make sense the couple of old
> suggestions above, though I expect your knowledge has already advance past
> this old stuff.
>
> Best regards,
>
> Dan
>
> *From:* Cfrg <[email-masked]> *On Behalf Of *Neil Madden
> *Sent:* Monday, April 27, 2020 10:12 AM
> *To:* CFRG <[email-masked]>
> *Subject:* [Cfrg] Multi-recipient public key authenticated encryption
>
> Hi all,
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmadden-2Djose-2Decdh-2D1pu-2D03&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=pABr2aBl1c_ofW8vypgq6rz4tGVZWkxu0IU_RSNb_L4&s=E_agQvNgeBlLsyPF6xyJ1TFQLBAJsGTY1FJf7EK3iqs&e=>
>
> Kind regards,
>
> Neil Madden
> ------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 29 Apr 2020 18:16:27 -0400

I am probably missing something here,,,

but this sounds like the problem MLS is solving?

Multiple recipients of an encrypted message.
Proof of single sender.

They had to invent? the ratchet tree.

?

On 4/27/20 10:12 AM, Neil Madden wrote:
> feedback from members of CFRG about solutions to a particular issue if 
> any of you have time.
>
> confidentiality and sender authentication using public key 
> cryptography then the only option is to both sign and then encrypt the 
> message. This is expensive because it involves multiple passes over 
> the message and results in a very bulky nested message structure with 
> two layers of base64-encoding.
>
> Given that many uses of this sign-then-encrypt pattern do not require 
> the strong security properties of signatures, I have proposed [1] a 
> public key authenticated encryption mode based on NIST’s one-pass 
> unified model from SP 800-56A. This avoids the nested structure and 
> means that you don’t need multiple cryptographic primitives. The 
> proposed algorithm uses two ECDH key agreements: one between the 
> sender’s ephemeral private key and the recipient’s long-term public 
> key; and a second between the two parties’ long term keys. The two 
> shared secrets are concatenated and passed through a KDF along with 
> some context arguments. For a single recipient this achieves sender 
> authentication (subject to replay), and the single recipient case is 
> what I am primarily concerned about.
>
> JOSE’s ECDH-ES+A256KW algorithm family in which the message is 
> encrypted using a random Content Encryption Key (CEK) and then the CEK 
> is encrypted for each recipient using AES-KeyWrap with the 
> ECDH-derived key. As I then mention in the security considerations 
> this leads to any recipient being able to produce a forgery using that 
> CEK and claim it came from the original sender:
>
> seemed like an acceptable trade-off. However, I have since been 
> contacted by people who would like to use this draft for 
> multi-recipient messages and would not like to fall back on a nested 
> signature structure.
>
> An initial proposal was to solve this by simply including the MAC tag 
> from the content encryption in either the per-recipient payload 
> (encrypted using AES-KeyWrap) or as an additional context field to the 
> KDF. But the MAC is computed using the CEK that is known to all 
> recipients, so for this to be secure would require second preimage 
> resistance of the MAC with a known key, which cannot be guaranteed for 
> JOSE because it supports content encryption using AES-GCM for which 
> second preimages can be trivially computed if you know the key.
>
> would be to include a collision-resistant hash of entire ciphertext 
> (and IV and associated data) in the KDF. This is unfortunate as it 
> requires another pass over the entire message when we’ve already 
> encrypted and MACed, but it appears to be a solution and at least is 
> no more inefficient than the original signed-then-encrypted approach 
> which also needs to hash the entire message.
>
> So two questions:
>
> symmetric AE) in the per-recipient KDF calculation sufficient to 
> prevent forgeries in the multi-recipient setting?
>
> 2. Are there more efficient alternatives that don’t assume 2nd 
> preimage resistance of the underlying symmetric MAC?
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Apr 2020 02:56:24 +0000

Neil Madden <[email-masked]> writes:

>authenticated encryption mode based on NIST’s one-pass unified model from SP
>800-56A. This avoids the nested structure and means that you don’t need
>recipient’s long-term public key; and a second between the two parties’ long
>term keys. The two shared secrets are concatenated and passed through a KDF
>along with some context arguments. For a single recipient this achieves
>sender authentication (subject to replay), and the single recipient case is

Maybe I'm missing something about JOSE here, but rather than introducing
complex and exotic new encryption modes, couldn't you just define a signed +
encrypted message format like PGP and S/MIME have been using for thirty years
now?

Peter.

---

From: Neil Madden <[email-masked]>
Date: Thu, 30 Apr 2020 07:38:04 +0100

> encrypted message format like PGP and S/MIME have been using for thirty years

Firstly, is an encryption scheme that has been standardized by NIST for 14 years really exotic? Or do you mean hashing the ciphertext for integrity is exotic?

When you say to instead use a signed + encrypted message format, do you mean a proper signcryption mode or do you just mean a generic composition of signatures and encryption? The latter is what JOSE already supports, and I could just have defined a way to remove the extra base64-encoding. But such a naive composition has its own problems such as [1] (known back in 2001) and [2] showed that there are surprisingly subtle conditions to consider. Part of the rationale for the new algorithm was that I have seen developers repeatedly make exactly these mistakes when combining signing and encryption in JOSE.

In the single recipient setting, it seems to me that the DH solution is significantly simpler. Indeed, I was able to implement it on top of our existing support for ECDH-ES encryption in a few dozen lines of code (mostly just refactoring the API to supply the additional key). Given that JOSE is mostly used for JWTs and JWTs only support single-recipient encryption I’d prefer to stick to this algorithm and see if I can add a simple tweak to remove a sharp edge in the multi-recipient setting.

[1]: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>
[2]: https://eprint.iacr.org/2001/079 <https://eprint.iacr.org/2001/079> 

— Neil

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Apr 2020 08:45:09 +0000

Neil Madden <[email-masked]> writes:

>Firstly, is an encryption scheme that has been standardized by NIST for 14
>years really exotic? Or do you mean hashing the ciphertext for integrity is
>exotic?

Just because someone wrote about it somewhere in the past doesn't make it non-
exotic.  In particular I don't know which specific "one-pass unified model
from SP 800-56A" you're referring to since SP 800-56A is just a long shopping
list of everything anyone at NIST could come up with, but all of them are
pretty exotic and AFAICT unsupported in major crypto libraries.

>When you say to instead use a signed + encrypted message format, do you mean
>a proper signcryption mode or do you just mean a generic composition of
>signatures and encryption? The latter is what JOSE already supports, and I
>could just have defined a way to remove the extra base64-encoding

My question was really trying to find out whether this was an attempt to fix a
real problem or just an excuse to play around with a fancy crypto scheme, and
if what you're referring to is "6.1.1.2  (Cofactor) Full Unified Model, C(2e,
2s, ECC CDH) Scheme", an extraordinarily awkward and painful one to boot.  It
looks like it's the latter.

Peter.

---

From: Neil Madden <[email-masked]>
Date: Thu, 30 Apr 2020 10:17:37 +0100

> pretty exotic and AFAICT unsupported in major crypto libraries.

Err… https://www.google.com/search?hl=en&q=800%2D56a%20site%3Aietf.org <https://www.google.com/search?hl=en&q=800-56a%20site:ietf.org>

> looks like it's the latter.

No, it’s 6.2.1.2 (Cofactor) One-Pass Unified Model. For reference, Bouncy Castle implements the “extraordinarily awkward and painful” full unified model here:

https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/ECDHCUnifiedAgreement.java <https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/ECDHCUnifiedAgreement.java>

I’m struggling to understand why you’d think this is complicated. The one-pass unified is almost identical except the second DH would use the recipient’s static public key instead. It’s incredibly straightforward.

— Neil

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Apr 2020 09:29:38 +0000

Neil Madden <[email-masked]> writes:

>I’m struggling to understand why you’d think this is complicated.

Have you seen an end-user application built with Bouncy Castle that uses it
correctly?  I mean actually audited the code in the application to check that
they get it right?

(I've done code audits of programs that misuse DH/ECDH mechanisms for key
transport.  So far I've never found one that gets it right, and in several
cases I was unable to explain to the developers how to change their code to
use the mechanism securely.  I've had a writeup on this half-done for awhile
with the title "Libhairshirt vs libfootgun", really must get around to
finishing it).

Peter.