> Seems more like efficiency / economy trade-off. You don’t really need both. There’s no security reason for one or the other.
That's right. Thank you for clarifying what I wanted to say. Daisuke 2024年3月4日(月) 3:42 lgl island-resort.com <[email protected]>: > That’s helpful. > > If you read the paragraph before you get more context and more > understanding why there’s both. Seems more like efficiency / economy > trade-off. You don’t really need both. There’s no security reason for one > or the other. > > Using aad like Ilari said, seems good to me. > > LL > > > On Mar 3, 2024, at 1:33 AM, AJITOMI Daisuke <[email protected]> wrote: > > > I haven't been able to read through all of the long discussions so far, > but ... > > Ilari, even if you can’t say why, can you tell us where the text that >> prohibits use of both INFO and AAD is? > > > I think this is about the following in Section 8.1 of RFC9180: > > Applications that only use the single-shot APIs described in Section 6 >> should use the Setup info parameter for specifying auxiliary authenticated >> information. 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. > > > It's not prohibited, but it says "should not''. > > This essentially means that, in HPKE, In HPKE, both INFO and AAD serve the > same role of binding information from the application layer to the HPKE > process and the difference between INFO and AAD only comes down to whether > the same can be used across multiple EncryptionContexts (INFO) or not (AAD). > > I believe that at least the authors of HPKE regard both in this way. > > Best, > Daisuke > > 2024年3月2日(土) 4:23 lgl island-resort.com <[email protected]>: > >> >> On Feb 29, 2024, at 1:01 PM, Ilari Liusvaara <[email protected]> >> wrote: >> >> On Thu, Feb 29, 2024 at 11:04:57AM -0600, Orie Steele wrote: >> >> I think we actually agree here. >> >> The remaining point is just what to do in HPKE. >> >> 1. New header parameters, mandatory processing rules, mix >> content encryption algorithm into the KDF (via HPKE INFO). >> >> >> HPKE does not allow using both INFO and AAD for one message (I do not >> know why), and INFO has a short length limit (because it is used in >> ways that pretty much require buffering). >> >> So only AAD can be used. >> >> >> Illari, even if you can’t say why, can you tell us where the text that >> prohibits use of both INFO and AAD is? >> >> Note that COSE -25 and -29 allow the input of a salt into the KDF outside >> of COSE_KDF_Context. If we wanted to do similar in COSE-HPKE, use of the >> info parameter is the obvious place. >> >> I can’t see any technical reason that both couldn’t be used and I wonder >> if there is some reason we might want to allow COSE-HPKE users to be able >> to supply inputs to the KDF function. >> >> Or asked another way, what are the security trade-offs between AAD and >> INFO? There’s lots of security considerations in RFC 9180, but none seem to >> discuss this. >> >> I don’t see an issue here, but it would be nice to understand. >> >> Thx! >> >> (RFC 9180 is impossible to search because the variable names used in the >> Python code are so short. “info” occurs almost 200 times) >> >> LL >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
