On Sat, Nov 26, 2022 at 12:45:44PM +0900, AJITOMI Daisuke wrote: > > > > So umm, this might be a bit disruptive, but I’d like it to be > > considered. > > > One more proposal has come up and I'm having fun. > > I think your idea should be considered as one candidate solution > because it has a clear advantage for object code size. > > > HPKE-KDF => uint, > > HPKE-AEAD => uint, > > HPKE-KEM => uint, > > HPKE_Enc => bstr
Maybe name it "KEM ciphertext" instead of "HPKE_Enc", so later things might be able to reuse it. > Perhaps the following headers may need to be added as well. > > HPKE-Version => uint, I think that is bad idea, because nobody has any idea what the interface for next HPKE version (if there ever is one) will be like. For example, it might not have KDF separate from KEM (since separating those is not sound in adversarial setting). > HPKE-Mode => uint, I also think this is bad idea, as the properties of the modes are rather different. Substituting mode_base in perfectly reasonable place with mode_auth can result something flawed. > HPKE-PSK-ID => bstr, Not needed if there is no mode_psk or mode_authpsk. > > For a typical COSE-HPKE message, it would be about two bytes bigger > > than the HPKE sender array and smaller than the HPKE sender map. > > Yes, two bytes smaller than the HPKE sender map. > But I think we need to discuss whether we can consume 4 to 7 first > class (<24) header values only for HPKE. Yes, even four values off that range is pretty harsh (currently there are 17 such codepoints free). And trying to calculate explicit sizes, I get that the difference to sender array is only 1 byte (difference to sender map is 2). This assumes KEM can be omitted, like in sender array/map. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
