Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CFA3A0D6B for ; Thu, 7 May 2020 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cornell.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBD7KBBmKlxA for ; Thu, 7 May 2020 13:38:06 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F3E3A0D79 for ; Thu, 7 May 2020 13:38:05 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id f13so1110265qkh.2 for ; Thu, 07 May 2020 13:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cornell.edu; s=g.20171207; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aGdGn48+fO4rXIUpt36Nck/ezTLNe6coGvfisOfklEo=; b=Xmk64g5nc8clsfbQEdNNoS2HcA7sVKcxxCM8IS8ehS9TxrQ3zxMaMTZyhx/u9Nlbi4 IlXlmU99RJO+WA5jyOcSrVIXSGtTD7bP8Mati3eNGudj/aGCPPpips19zUXxXuWfXvkn oZ809lcZzBQEYh+7c5+HSQbeiHPROOkZUAd8KevpwYAI84P0DlBroOWKs/VvMNohguFg pfoDSU0Cta3xA9XRNkPigu0W60qJkBPSpznKFapVhb7iOsdyimPyba2VH0BYAR6GCgoa 2a1ghDjo9fnouWNi+i2EWv7sdkKN2Gkc4XrhMJDWK3IHRP+OihGSg4EgisvLxejEfSBL d8Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aGdGn48+fO4rXIUpt36Nck/ezTLNe6coGvfisOfklEo=; b=JvdjwAUlLBAsKmOv4s1N3YDN/9kr3SheTHgUCR5W0HeTQ0ggfi4F190Wvgev1vZ9bB r36Ci72pfbMyqv0SrZRg12m4kIW655a550XnVdok+NXFyqVcfUSE8qwdHM5Xl1oIoI4K kkjEIiTkGp3c1g7auMEK5co/SgX7F5MtWOAuPInXnhkW/mFs5qU4ppXn9vcUqWXtoGin eDbt2AMotyFH8Z3uPqRpjRxCfX2P4CMGEP8bzCa0SZ2+n7cICqMhdVsCogqDCBbkuswZ NgT56DDzXFQoRavnStGuZFPPspKWuVW6x9xZpViATwJZxJdkrVvT0xUNBBNk2eqVUKNl gZ8Q== X-Gm-Message-State: AGi0PubGEf82sx5Dp07e7wTcWleVTeVoiRyFBCXC0vT5sdKFXwC+kBMX 8B5OLfTqtqN2JxqeZ1DdLaLIoPAukd16Ukn7ogUBRg== X-Google-Smtp-Source: APiQypLvRdvHUa9yuLO0E6IvJ5bbrwoUucGiiSwcS33ezjbLDBsNh9elvTOB8nv0U+lzEUGeXs7Dabs3EfDXeJqAisg= X-Received: by 2002:a37:a886:: with SMTP id r128mr16125514qke.148.1588883884531; Thu, 07 May 2020 13:38:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Grubbs Date: Thu, 7 May 2020 16:37:53 -0400 Message-ID: To: Neil Madden Cc: Mike Jones , CFRG Content-Type: multipart/alternative; boundary="00000000000086f7b405a514db22" Archived-At: Subject: Re: [Cfrg] Multi-recipient public key authenticated encryption X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 20:38:14 -0000 --00000000000086f7b405a514db22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Oops - Neil, I interpreted your earlier message to mean that JOSE does indeed only support GCM. (My apologies for not checking this before replying.) On Thu, May 7, 2020 at 11:16 AM Neil Madden wrote= : > The issue is not that JOSE only supports GCM (it doesn=E2=80=99t). The is= sue is > that JOSE supports GCM and allows that choice independently of the key > agreement algorithm. Hence if GCM is not appropriate for this new algorit= hm > then I need to add text forbidding it in this context - i.e. that > implementations MUST reject a JWE with =E2=80=9Calg=E2=80=9D:=E2=80=9DECD= H-1PU+A128KW=E2=80=9D and > =E2=80=9Cenc=E2=80=9D:=E2=80=9DA256GCM=E2=80=9D for example. > > On 7 May 2020, at 16:10, Mike Jones wrote: > > I=E2=80=99m confused by the statement =E2=80=9CJOSE only supports GCM=E2= =80=9D. There=E2=80=99s an IANA > registry for JOSE algorithms at > https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption= -algorithms > and any additional desired algorithms can be added there. > > -- Mike > > *From:* Cfrg *On Behalf Of *Neil Madden > *Sent:* Thursday, May 7, 2020 7:27 AM > *To:* pag225@cornell.edu > *Cc:* CFRG > *Subject:* : [Cfrg] Multi-recipient public key authenticated encryption > > That is interesting, thanks. JOSE does also support AES-CBC + HMAC (EtM), > so it may perhaps then be simpler to forbid the use of GCM for > multi-recipient messages in this spec and save myself a lot of trouble. I= t > seems from your papers that CBC+HMAC is one of the schemes you looked at > and it would be compactly committing, so this is fortunate. > > > > On 7 May 2020, at 14:39, pag225@cornell.edu wrote: > > > Oh ok, it=E2=80=99s too bad JOSE only supports GCM. You should be careful= with > using plain GCM in these multi-receiver settings - because it=E2=80=99s > non-committing, it=E2=80=99s possible to craft a single ciphertext that d= ifferent > receivers decrypt to different plaintexts. > > > On May 7, 2020, at 7:28 AM, Neil Madden wrote: > > =EF=BB=BFApologies, I forgot to respond to this. I think the ccAE approac= h is a > nice way of solving the problem. Unfortunately, JOSE allows specifying th= e > key exchange algorithm and AEAD cipher entirely independently so I have t= o > have a solution that works with the AES-GCM based AEADs that are already > part of the standard. But I will read these papers closely, because I do > think the security notions are very similar to what I=E2=80=99m trying to= achieve. > > =E2=80=94 Neil > > > On 28 Apr 2020, at 16:14, Paul Grubbs wrote: > > 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 =3D (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 > 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 requir= es > 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 g= et > Alice to authenticate arbitrary messages to himself and Bob then he can u= se > 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 asserti= on > 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=E2=80=99s an incentive for me to also change the KDF in the scheme f= rom JOSE=E2=80=99s > 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 o= f > the ciphertext. > > [1] https://saltpack.org/encryption-format-v2 (scroll down to Payload > Packets) > > Best, > > Neil > > > On 27 Apr 2020, at 16:19, Dan Brown wrote: > > 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 > =E2=80=9Cnote=E2=80=9D. > > 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 pas= t > this old stuff. > > Best regards, > > Dan > > *From:* Cfrg *On Behalf Of *Neil Madden > *Sent:* Monday, April 27, 2020 10:12 AM > *To:* CFRG > *Subject:* [Cfrg] Multi-recipient public key authenticated encryption > > 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 an= y > 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 i= s > expensive because it involves multiple passes over the message and result= s > in a very bulky nested message structure with two layers of base64-encodi= ng. > > 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 ke= y > authenticated encryption mode based on NIST=E2=80=99s one-pass unified mo= del from > SP 800-56A. This avoids the nested structure and means that you don=E2=80= =99t need > multiple cryptographic primitives. The proposed algorithm uses two ECDH k= ey > agreements: one between the sender=E2=80=99s ephemeral private key and th= e > recipient=E2=80=99s long-term public key; and a second between the two pa= rties=E2=80=99 > long term keys. The two shared secrets are concatenated and passed throug= h > 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 =E2=80= =9CK=E2=80=9D > one-way pattern, but my hands are waving quite a lot here). > > To support multiple recipients I copied the existing pattern used in > JOSE=E2=80=99s ECDH-ES+A256KW algorithm family in which the message is en= crypted > 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 a= nd > would not like to fall back on a nested signature structure. > > An initial proposal was to solve this by simply including the MAC tag fro= m > the content encryption in either the per-recipient payload (encrypted usi= ng > 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 anoth= er > pass over the entire message when we=E2=80=99ve already encrypted and MAC= ed, 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 enti= re > 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=E2=80=99t assume 2nd pr= eimage > resistance of the underlying symmetric MAC? > > [1]: https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 > > > 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-publi= c > information. Any use of this information by anyone other than the intende= d > 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 unlawf= ul. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > > --00000000000086f7b405a514db22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops - Neil, I interpreted your earlier message to mean th= at JOSE does indeed only support GCM. (My apologies for not checking this b= efore replying.)

On Thu, May 7, 2020 at 11:16 AM Neil Madden <neil.e.madden@gmail.com> wrote:
<= /div>
The issue is not that JOSE only supports GCM (it does= n=E2=80=99t). The issue is that JOSE supports GCM and allows that choice in= dependently of the key agreement algorithm. Hence if GCM is not appropriate= for this new algorithm then I need to add text forbidding it in this conte= xt - i.e. that implementations MUST reject a JWE with =E2=80=9Calg=E2=80=9D= :=E2=80=9DECDH-1PU+A128KW=E2=80=9D and =E2=80=9Cenc=E2=80=9D:=E2=80=9DA256G= CM=E2=80=9D for example.

On 7 Ma= y 2020, at 16:10, Mike Jones <Michael.Jones@microsoft.com> wrote:

=
I=E2= =80=99m confused by the statement =E2=80=9CJOSE only supports GCM=E2=80=9D.= =C2=A0 There=E2=80=99s an IANA registry for JOSE algorithms athttps://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryp= tion-algorithms=C2=A0an= d any additional desired algorithms can be added there.
=C2=A0
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike
=C2=A0
From:=C2=A0Cfrg <cfrg-bounces@irtf.org>=C2=A0= On Behalf Of=C2=A0Neil Madden
Sent:=C2=A0<= /span>Thursday, May 7, 2020 7:27 AM
To:=C2=A0pag225@cornell.edu
Cc:=C2=A0CFRG <cfrg@irtf.org>
Subject:=C2=A0: [Cfrg] Multi-recipient public key authenticated encrypti= on
=C2=A0
=
That is interesting, thanks. JOSE does also support AES-CBC + HMA= C (EtM), so it may perhaps then be simpler to forbid the use of GCM for mul= ti-recipient messages in this spec and save myself a lot of trouble. It see= ms from your papers that CBC+HMAC is one of the schemes you looked at and i= t would be compactly committing, so this is fortunate.
<= /div>
=C2=A0
= =C2=A0
On 7 May 2020, at 14:39,=C2=A0pag225@cornell.edu=C2=A0wrote:=
=C2=A0

Oh ok, it=E2=80=99s too bad JOSE only supports GCM. You sho= uld be careful with using plain GCM in these multi-receiver settings - beca= use it=E2=80=99s non-committing, it=E2=80=99s possible to craft a single ci= phertext that different receivers decrypt to different plaintexts.=C2=A0=



On May 7, 202= 0, at 7:28 AM, Neil Madden <neil.e.madd= en@gmail.com> wrote:

=EF=BB=BFApologi= es, I forgot to respond to this. I think the ccAE approach is a nice way of= solving the problem. Unfortunately, JOSE allows specifying the key exchang= e algorithm and AEAD cipher entirely independently so I have to have a solu= tion that works with the AES-GCM based AEADs that are already part of the s= tandard. But I will read these papers closely, because I do think the secur= ity notions are very similar to what I=E2=80=99m trying to achieve.<= u>
=C2=A0
= =E2=80=94 Neil


On = 28 Apr 2020, at 16:14, Paul Grubbs <pag225@c= ornell.edu> wrote:
=C2=A0<= u>
I think you can get away without the additi= onal hash of the ciphertext entirely if you use a compactly committing AEAD= (ccAE) scheme [1]. A ccAE has a two-part ciphertext C =3D (C1, C2) with th= e property that C2 is a binding commitment to the plaintext and key. At lea= st intuitively, then, using C2 in the KDF prevents a receiver from modifyin= g the message. (This is morally similar to including the MAC tag in the KDF= , as suggested,=C2=A0but sidesteps questions about MAC security and may be = faster if optimal-rate schemes like HFC [2] are used.) I haven't analyz= ed this construction formally, though, so take this advice with a bit of sa= lt.
=C2=A0
=
=C2=A0
=
=C2=A0
On Tue, Apr 28, 202= 0 at 8:30 AM Neil Madden <neil.e.madden= @gmail.com> wrote:
Thanks, section 5 of the eprint is very useful. In that you di= scuss the solution of including the MAC tag in the KDF and you say that thi= s requires collision resistance of the MAC, where I had previously assumed = only 2nd preimage resistance would be enough. As I understand it, the poten= tial attack is that if Charlie has access to an Alice-oracle by which he ca= n get Alice to authenticate arbitrary messages to himself and Bob then he c= an use this to perform a collision search to find two messages with the sam= e MAC tag (if the MAC is not collision resistant).
=
=C2=A0
I think this activ= e attack would also apply to my proposed solution using a hash of the authe= nticated 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 attack= s would be limited to ~128 bit level. Perhaps that=E2=80=99s an incentive f= or me to also change the KDF in the scheme from JOSE=E2=80=99s existing Con= cat-KDF to HKDF with SHA-512.
=C2=A0
I think the same attack would als= o apply to saltpack [1], if I understand correctly? In saltpack a per-recip= ient MAC is calculated over a SHA-512 of the ciphertext.
=C2=A0
[1]=C2= =A0https://saltpack.org/encrypt= ion-format-v2=C2=A0(scroll down to Payload Packets)
=
=C2=A0
Best,
=C2=A0
Neil


= On 27 Apr 2020, at 16:19, Dan Brown <d= anibrown@blackberry.com> wrote:
= =C2=A0
Hi Neil,
I too have encountered this interesting and well-k= nown (perhaps not widely-known) problem.
See=C2=A0https://tools.ietf.org/ht= ml/rfc3278#section-4.1.2=C2=A0the very short =E2=80=9Cnote=E2=80= =9D.
=C2=A0
I forget the details of the various claimed past solutions= , but will try to remember, maybe in a couple weeks.=C2=A0 Meanwhile, since= the problem is fresh in your mind, and you might try to make sense the cou= ple of old suggestions above, though I expect your knowledge has already ad= vance past this old stuff. =C2=A0=C2=A0
=C2=A0
Best regards,=
=C2=A0
Dan
=C2=A0
cfrg-bounces@ir= tf.org>=C2=A0On Behalf Of=C2=A0Neil Madden
Sent:=C2= =A0Monday, April 27, 2020 10:12 AM
To:=C2=A0CFRG <cfrg@irtf.org>
Subject:=C2=A0[Cfrg] Multi-reci= pient public key authenticated encryption
=C2=A0
Hi all,
=C2=A0
I am working on an enhancement to the JOSE stand= ards and would like feedback from members of CFRG about solutions to a part= icular issue if any of you have time.
<= div>
=C2=A0
In = JOSE currently if you wish to create a message that has both confidentialit= y and sender authentication using public key cryptography then the only opt= ion 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 n= ested message structure with two layers of base64-encoding.
=C2=A0
<= div>
Given that many uses of this sign-then-encrypt pattern d= o not require the strong security properties of signatures, I have proposed= [1] a public key authenticated encryption mode based on NIST=E2=80=99s one= -pass unified model from SP 800-56A. This avoids the nested structure and m= eans that you don=E2=80=99t need multiple cryptographic primitives. The pro= posed algorithm uses two ECDH key agreements: one between the sender=E2=80= =99s ephemeral private key and the recipient=E2=80=99s long-term public key= ; and a second between the two parties=E2=80=99 long term keys. The two sha= red secrets are concatenated and passed through a KDF along with some conte= xt arguments. For a single recipient this achieves sender authentication (s= ubject to replay), and the single recipient case is what I am primarily con= cerned about.
=C2=A0<= /u>
(If you squint this is also= roughly similar to the Noise framework =E2=80=9CK=E2=80=9D one-way pattern= , but my hands are waving quite a lot here).
=C2=A0
To support multiple recipients I copied the existing pattern used in JO= SE=E2=80=99s ECDH-ES+A256KW algorithm family in which the message is encryp= ted using a random Content Encryption Key (CEK) and then the CEK is encrypt= ed for each recipient using AES-KeyWrap with the ECDH-derived key. As I the= n 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 origina= l sender:
=C2=A0<= u>
=C2=A0=C2=A0 =
When Key Agreement with Key Wrapping is used, with the same Content<=
u>
=C2=A0=C2=A0 Encryption Key (CEK) reused for mul=
tiple recipients, any of those
=C2=A0=C2=
=A0 recipients can produce a new message that appears to come from the
=C2=A0=C2=A0 original sender.=C2=A0 The new m=
essage will be indistinguishable from a
=
=C2=A0=C2=A0 genuine message from the original sender to any of the other
=C2=A0=C2=A0 participants.=C2=A0 To avoid =
this attack, the content SHOULD be encrypted
=C2=A0=C2=A0 separately to each recipient with a unique CEK or a neste=
d signature
=C2=A0=C2=A0 over the content=
 SHOULD be used.
=C2=A0=
Because I am primarily interes= ted 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 ne= sted signature structure.
An initial prop= osal was to solve this by simply including the MAC tag from the content enc= ryption in either the per-recipient payload (encrypted using AES-KeyWrap) o= r 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 req= uire second preimage resistance of the MAC with a known key, which cannot b= e guaranteed for JOSE because it supports content encryption using AES-GCM = for which second preimages can be trivially computed if you know the key.
=C2=A0
Assuming that a per-recipient MAC is too m= uch overhead, an alternative would be to include a collision-resistant hash= of entire ciphertext (and IV and associated data) in the KDF. This is unfo= rtunate as it requires another pass over the entire message when we=E2=80= =99ve already encrypted and MACed, but it appears to be a solution and at l= east is no more inefficient than the original signed-then-encrypted approac= h which also needs to hash the entire message.
=C2=A0
So two questions:
= =C2=A0
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-reci= pient setting?
=C2=A0=
2. Are there more efficien= t alternatives that don=E2=80=99t assume 2nd preimage resistance of the und= erlying symmetric MAC?
= =C2=A0
=C2=A0
Kind regards,
<= div>
=C2=A0
Nei= l Madden
This transmission (including any attachments) may contain= confidential information, privileged material (including material protecte= d by the solicitor-client or other applicable privileges), or constitute no= n-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 unlawfu= l.
=C2= =A0
_____________________________________= __________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mai= lman/listinfo/cfrg

--00000000000086f7b405a514db22--