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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
