Hi Hannes, Daisuke, you are proposing to put no information as shown below (snippet > from Github PR). IMHO information has to be provided on how the plaintext > is encrypted with the CEK. In the example below this information is absent.
I just meant to say that HPKE should be completed in one layer, but yes, my example is false. I think I cut corners a little too much. At least, there is no reason for my example to be a two-layered structure. I'll update the example and post it to PR #9. Best, Daisuke 2022年11月17日(木) 20:28 Hannes Tschofenig <[email protected]>: > Hi Daisuke, > > > > Let us provide a bit of background about the multiple recipient setup. > > > > Imagine a sender wants to encrypt plaintext and wants to share it with > multiple recipients. > > (The goal here is that all recipients receive the same plaintext. If you > want to send different plaintext to different recipients then we are back > to one-layer structure (Section 3.1.1 in the draft)). > > > > The sender encrypts a CEK (Content Encryption Key) using HPKE and places > the result in the recipient structure. Multiple recipients implies multiple > recipient structures. Each encrypted CEK looks different but the CEK is the > same. > > In a second step, the CEK is used to encrypt the plaintext (such as a > firmware image). > > > > (With AES-KW, used in the SUIT firmware encryption draft, there is another > option. I am not describing it here.) > > > > Daisuke, you are proposing to put no information as shown below (snippet > from Github PR). IMHO information has to be provided on how the plaintext > is encrypted with the CEK. In the example below this information is absent. > > > > 96_0([ > > h'', // **This is the mandatory point to be fixed.** > > {}, > > h'', > > [ > > [ > > h'a10120', > > { > > 4: h'3031', > > -4: { > > 1: 16, > > 5: 1, > > 2: 1, > > 3: h'040..90', > > }, > > }, > > h'5f..a9', > > ], > > ], > > > > Ciao > > Hannes > > > > > > *From:* COSE <[email protected]> *On Behalf Of * AJITOMI Daisuke > *Sent:* Wednesday, November 16, 2022 11:25 PM > *To:* Laurence Lundblade <[email protected]> > *Cc:* Ilari Liusvaara <[email protected]>; cose <[email protected]> > *Subject:* Re: [COSE] AEAD algorithm ID for HPKE > > > > Ilari has said most of what I want to say but let me add one point. > > > From reading the PR#9 more carefully I see that you put HPKE as the > algorithm ID in both the body header and recipient headers. > > > As I mentioned in the following comment, I think that the alg value for > the first layer should not be "HPKE" in the Layer Two example and I asked > Hannes to fix it. > > https://github.com/cose-wg/HPKE/pull/9#issuecomment-1288984512 > > Best, > Daisuke > > 2022年11月17日(木) 4:48 Laurence Lundblade <[email protected]>: > > > > > > On Nov 16, 2022, at 9:00 AM, Ilari Liusvaara <[email protected]> > wrote: > > > > On Wed, Nov 16, 2022 at 08:21:21AM -0800, Laurence Lundblade wrote: > > > It’s taking some time for me to understand HPKE well. Patience > appreciated. Let me ask a couple questions that seem important and > clarifying and have you confirm my understanding. > > Is the bulk AEAD operation (JUST the bulk operation) on the pt that > produce the ct the same for HPKE as for the methods in COSE section > 6? They both can use AES 128 GCM, but it looks to me like they aren’t > the same because HPKE has a stateful encryption context (HPKE section > 5.2) and COSE doesn’t. You might be able to use the same AES 128 GCM > library for both, but the surrounding inputs don’t seem compatible. > > > Yes, all the surrounding stuff is different, the two only unify in > the raw AES 128 GCM implementation. > > In my implementation, the common part is just the methods > > - EncryptionKey::encrypt_buffer_to_buffer() > - DecryptionKey::decrypt_buffer_to_buffer() > > Which implement raw AES-GCM/Chacha20-Poly1305 (EncryptionKey/ > DecryptionKey also contains the algorithm used) > > > > Makes sense. > > > > In this case the body parameter algorithm ID is clearly NOT one of the > COSE content encryption algorithms registered today from section 4 of RFC > 9053 > <https://www.rfc-editor.org/rfc/rfc9053.html#name-content-encryption-algorith>. > Definitely not A128GCM (1)…, definitely not AES-CCM-16-64-128 (10). > > > > > > > > Are we considering whether and how reuse of the HPKE encryption > context fits into COSE? It is probably not useful in COSE (but > can see it is critical in TLS). > > > I don't think there has ever been a proposal for COSE-HPKE to reuse > the context. > > > > OK. Just checking because I haven’t read all the back history here. Makes > sense. Possibly the COSE-HPKE draft should mention that. > > > > > > How will multiple recipients be handled with COSE-HPKE? In one case > > one HPKE recipient may use Edwards curves and another HPKE recipient > NIST curves. There’s also the possibility that one recipient uses HPKE > and another something that is not HPKE like AES key wrap from RFC 9053 > section 6.2. > > It kind of seems like HPKE was not designed for multiple recipients > because it was designed in the TLS context. You mentioned two-layered > HPKE in a previous message. What is that? > > > Use COSE to encrypt with freshly generated random key, then use HPKE to > encrypt that random key N times, and stick the N HPKE encryptions as > recipients of the message. > > > > Makes sense. It parallels section 6.4 of RFC 9052 > <https://www.rfc-editor.org/rfc/rfc9053.html#name-key-agreement-with-key-wrap>, > right? It’s two layers of encryption (content and key wrap) plus key > agreement, right? > > > > In this case the body parameter algorithm ID IS clearly one of the COSE > content encryption algorithms registered today from section 4 of RFC 9053 > <https://www.rfc-editor.org/rfc/rfc9053.html#name-content-encryption-algorith>. > One of A128GCM (1)…, AES-CCM-16-64-128 (10, ...). The algorithm ID in the > COSE_Recipient is HPKE. > > > > I believe the COSE-HPKE draft should address this to be complete. Seems > like some details to work out to be sure it is right. > > > > > > My first thought for multiple recipients in COSE-HPKE is to use the > > facilities COSE has, but I’m not sure how to line that up with the > way AEAD is integrated into the HPKE encryption context. It does > seem necessary to address this now. > > > That's the way it is done. > > The first layer (bulk encryption) in case of multiple recipients can > not use HPKE because it is symmetric-only operation, where HPKE always > involves asymmetric step (it is possible to do asymmetric-only, via > exporters but not vice versa). > > > > Glad we’re getting some alignment here. :-) > > > > LL > > > > > > > > > > > > > > > So focusing on the COSE body header parameter algorithm ID, it seems > that it should be a COSE algorithm ID if it is doing what COSE says > to do even if the recipient structure is HPKE, but if it is not > compatible with COSE’s use of AEAD, then it should be something else > (which must be in the COSE registry). Not saying which way to go here. > Just building up some facts. > > > Yes, if doing two-layer (required for multi-recipient): > > - The main message algorithm is old COSE algorithm id (e.g., 24 for > Chacha20-Poly1305) > - The recipient algorithm is HPKE (whatever the numeric value will be). > > > Then there are subtle differences between one- and two-layer even for > single recipient: My implementation only ever attempts one bulk > decryption. In case there are multiple applicable keys, in case of one- > layer, it gives up if the first key is wrong, in case of two-layer, it > will proceed to try the remaining keys. This limitation comes from the > way the code handles very large messages (it is not bound by system RAM > size). > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
