Hello, Since I am unable to join the IETF meeting this week, I wanted to weigh in on the use of "info" in the JOSE HPKE proposal. There must be an option for the parties to agree on the “info” parameter contents. I don’t want a requirement to use the KDF structure, but an option to use it is fine as long as I can specify my own private value instead and apu, apv are still optional. One of the advantages of HPKE for me is to avoid the KDF structure, apu, apu, etc. I think this fits into the discussion below, but I wanted to summarize it.
Also, I would like to ask to register HPKE-P256-SHA256-A256GCM too. This aligns with the Apple published API for HPKE Cipher suites and is similar to using ECDHE with A256CGM. While we do not consider A128 strong enough, I am not asking to leave it out of the registry. https://developer.apple.com/documentation/cryptokit/hpke/ciphersuite HPKE.Ciphersuite | Apple Developer Documentation developer.apple.com Thanks! -matt > On Jul 11, 2024, at 9:47 AM, Matt Chanda <[email protected]> wrote: > > > >> 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]
