On Tue, Apr 18, 2023 at 10:17:04AM -0700, Laurence Lundblade wrote: > > > On Apr 18, 2023, at 6:45 AM, AJITOMI Daisuke <[email protected]> wrote: > > > > Hi folks, > > > > I would like to address the following issue created by Hannes: > > https://github.com/cose-wg/HPKE/issues/25 > > <https://github.com/cose-wg/HPKE/issues/25> > > > > Previously, I made a post as follows: > > > > At the very least, until now, I believed that the info value for > > HPKE should be an empty string. The reason is that HPKE interface > > used in COSE is essentially the Single-shot API, and a single HPKE > > encryption context is not used across multiple encryption/decryption > > processes. In other words, aad alone is sufficient. As I mentioned > > before, RFC9180 Section 8.1 also says "Implementations which only > > expose single-shot APIs should not allow applications to use both > > Setup info and Context aad or exporter_context auxiliary information > > parameters". I will also give it some more consideration though. > > > > Whether it is a Single-shot API or not is not important. What is > > important is that in COSE-HPKE, there is always only one > > encryption/decryption process performed on a single encryption > > context. This fact does not change whether or not the Single-Shot > > API is used. Therefore, there is absolutely no benefit in using > > both "info" and "aad" simultaneously. Using both does not improve > > security, so it's sufficient to use just one of them. That's why > > I argued that "info" should be an empty string, but honestly, > > I'm not very confident that this argument is correct. I would > > like to hear the opinions of Ilari, Laurence and others as well.
If HPKE recommends against using both in one-shot operation (and COSE-HPKE is always one-shot as you note), then one should only use aad. - aad possibly includes external aad. Sticking that to info would be very weird. - Aad does not cause key mismatches, which cause at least theoretical problems in many AEADs (whereas AEADs are required to be robust to aad mismatches). - Implementations can process aad faster than info (it is polymac instead of HMAC). - Implementations probably support larger aad than info. > As much as I’d like less complexity (and a simpler t_cose API), > I think you are right about this, Ajitomi. > > I think it should be based on the Context Information Structure in > RFC 9053 > <https://www.rfc-editor.org/rfc/rfc9053.html#name-context-information-structu>. > > That will result in common code, designs and APIs for all the COSE > key agreement methods that use an HKDF. There are two problems with this: 1) HPKE uses the KDF with inconsistent lengths, so the SuppPubInfo.keyDataLength makes no sense. 2) COSE_KDF_Context does not seem to be good fit at what applications might want to do with the context. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
