On Wed, Jan 24, 2024 at 04:58:31PM +0200, Ilari Liusvaara wrote: > On Wed, Jan 24, 2024 at 08:09:41AM -0600, Orie Steele wrote: > > I will open a new PR that just uses the hkdf, and add some details so it is > > easier to compare approaches. > > > > I feel like the hkdf approach does not work when you communicate the key > > using key wrapping, and it is not generated from ECDH, but better examples > > will hopefully make this clearer. > > There are two different attacks: > > 1) JOSE-HPKE crossmode attack. > 2) CTR/CBC Oracle attack (LAMPS slide deck).
Here is updated version of idea earlier with crossmode attack fixed (the earlier version already prevented the CTR/CBC oracle attack): 1) Integrated Encryption mode: - Header "enc" SHALL be absent. - Header "alg" SHALL be a JOSE-HPKE algorithm. - Generalized JWE JSON serialization MUST NOT be used. - HPKE aad is constructed according to JWE section 5.1 step 14. - HPKE info is empty. - HPKE plaintext is (possibly compressed) message. - JWE Encrypted Key is HPKE enc output. - JWE Initialization Vector is emtpy. - JWE Ciphertext is HPKE ciphertext output. - JWE Authentication Tag is empty. 2) Key Encryption mode: - Header "enc" SHALL be set according to JWE. - Recipient header "alg" SHALL be a JOSE-HPKE algorithm. - HPKE aad is "Key Encryption". - HPKE info is empty. - HPKE plaintext is CEK. - JWE Encrypted Key is concatanation of HPKE enc and HPKE ciphertext. (No length markers needed). (I like this a good bit more than the present approach. The cleanest one I have come across so far.) The space in Key Encryption aad prevents crossmode attack. Never ignoring "enc" prevents CTR/CBC oracle attack. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
