Has this issue been addressed in JWE prior to HPKE? It seems like simply saying, when an hpke alg value is in a protected header, there must not be an enc value in the protected header, solves this.
You will know which serialization you are using with HPKE JWE because the protected headers are always used as AAD to seal and open, so any attempt to switch from one to the other ( by switching alg and enc ) will break and those operations. Is anything more needed? I think it's best for us to avoid creating new serializations if possible. This means compact is single recipient, and JSON is multiple recipient or single recipient. Even if we removed the "only alg or enc, never both criteria", I am not sure it would be a problem. Being able to take a multiple recipient encrypted content encryption key, and turn it into a single recipient 32 byte plaintext after decryption is weird... But I am not sure it reflects anything exploitable, beyond what you would naturally get from breaking encap and decap... These are certainly the right question to be asking though. OS On Sun, Jan 28, 2024, 2:54 PM Ilari Liusvaara <[email protected]> wrote: > On Sun, Jan 28, 2024 at 11:55:20AM -0600, Orie Steele wrote: > > > 3. The AAD for HPKE Seal and Open MUST be the same as the AAD used > > with AEAD for content encryption ("protected" + "." + "aad" or just > > "protected" in case there is no "jwe aad"). > > Take a compact HPKE JWE for 32 byte payload and make flattened > JWE with the following: > > - Protected is protected of the original JWE > - Unprotected contains enc: A256GCM, and ek with encrypted key of > original JWE. > - Encrypted key contains ciphertext of original JWE. > - Initialization Vector, Ciphertext and Authentication Tag contain > something. > > Now try to decrypt that. Result is trying to decrypt the given > IV/ciphertext/tag using the original payload as the key... > > > Or if sender has put enc in unprotected bucket (which is allowed), do > the reverse of previous. Now the resulting JWE decrypts to the CEK... > > > I find the second one rather disturbing... > > > > > -Ilari > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
