: ) 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. Regards, OS On Thu, Jul 11, 2024 at 2:27 AM Ilari Liusvaara <[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]> 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] > To unsubscribe send an email to [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]
