> On Jul 11, 2024, at 9:00 AM, Orie Steele <[email protected]> wrote: > > : ) Ilari you've got a lot of patience, you've reminded me of hpke info > length restrictions several times now. > > I assume by setting info empty, HPKE internals are handling everything that > is needed here. > > If they are not, is is ok for us to write something like: > > For HPKE JWE Integrated Encryption and Key Encryption hpke-info SHOULD be > empty, however, if both sender and recipient agree, hpke-info can be set to > any value that is consistent with section ___ of RFC9180.
This would work for my use case, so I am in favor of it. > > Regards, > > OS > > On Thu, Jul 11, 2024 at 2:27 AM Ilari Liusvaara <[email protected] > <mailto:[email protected]>> wrote: >> On Wed, Jul 10, 2024 at 06:36:28PM -0500, Orie Steele wrote: >> > Hi Matt, >> > >> > In the other threads, Ilari has suggested using setup info in a manner >> > similar to how info is used with concat kdf in ECDH-ES. >> >> Maybe I was unclear. What I suggested was: >> >> - Key Encryption: >> * HPKE aad: ECDH-ES FixedInfo >> * HPKE info: empty. >> - Integrated Encryption: >> * HPKE aad: From JWE Section 5.1 step 14. >> * HPKE info: empty. >> >> There is 16 bytes of fixed stuff in ECDH-ES FixedInfo, leaving 48 bytes >> for enc, apu and apv. That is not enough. >> >> >> > On Wed, Jul 10, 2024, 6:07 PM Matt Chanda <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > > Hi Orie, >> > > >> > > The draft says: "The "Setup info" MUST NOT be used with either HPKE JWE >> > > Integrated Encryption and HPKE JWE Key Encryption." Could you provide >> > > some >> > > more information about this part? >> >> There are three problems with using setup info: >> >> - Some HPKE implementations error if trying to use both info and aad. >> - Info is limited to 64(!) bytes, which is not sufficient for JWE. >> - If context does not match, it leads to mismatched keys, which are >> not guaranteed to be handled sanely by AEAD... Probably not >> significant (but that is not something one wants to hear in crypto). >> >> >> > > RFC 9180 section 8.1 doesn't have this restriction unless using single >> > > shot APIs. I'm planning on using a nonce in the info field to make sure >> > > the key material is specific to the transaction per the advice on NIST >> > > 800-56A Appendix B. >> >> The 64 byte restriction is still there. Aad has no length limit. >> >> And aad works fine for binding context, because HPKE fails decryption on >> authentication failure. >> >> >> (And funkily enough, the recommendation is only on implementations that >> do not support multi-shot at all. So if implementation exposes multi- >> shot, it should let application use both info and aad in single-shot.) >> >> >> >> >> -Ilari >> >> _______________________________________________ >> jose mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > > -- > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > <https://transmute.industries/> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
