> 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
