Laurence & Ilari, there is text in the COSE HPKE draft on how to work with multiple recipients.
Section 3.2.1 offers the details, see https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-02#section-3.2.1 Let me know if the text is unclear. Ciao Hannes PS: FWIW we should be careful about designing the specification around a single implementation. -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Wednesday, November 16, 2022 6:01 PM To: cose <[email protected]> Subject: Re: [COSE] AEAD algorithm ID for HPKE 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) > 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. > 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. > 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). > 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 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
