On Wed, Jun 12, 2024 at 10:22:16PM -0500, Matt Chanda wrote: > > > > > >> If so, in my setup the ek is accessible after setting up the context > >> and it can be added to the header before calling seal (which used > >> the aad). > > > > The problem is that the protected headers are input to the whole > > operation, and thus can not be modifed. Splitting the operation into > > two (to allow modifying protected headers) would greatly increase > > complexity. > > I think I’m starting to understand what you are saying. If you are > not modifying the header as part of the encryption process, does > that mean you also set the epk before calling your encryption when > using EC DH?
Yes. With EC DH (with and without key wrapping): - Step 3 (key agreement operation) sets the epk. - Step 13 (compute Encoded Protected Header) fixes protected headers. - Step 15 (bulk encryption) does the bulk encryption. However, EC DH can not read protected headers (13 > 3). Similarly, Key Encryption could use headers: - Step 4 (encrypt the CEK) could set headers. - Step 13 (compute Encoded Protected Header) fixes protected headers. - Step 15 (bulk encryption) does the bulk encryption. However, Key Encryption can not read protected headers (13 > 4). > I suspect the answer is yes. If so, that is where we are different. > I explicitly do not allow the caller to pick the epk. I do this to > ensure that the epk is not recycled or replayed, and to ensure that > the private key for the epk is correctly discarded. You are probably > handing the same controls but at a layer above the encryption. > (Which is ok too). Since I consider the epk as part of the > encryption, it doesn’t matter to me if a different algorithm uses > an ek header instead of the epk. I think you are confusing direct and indirect HPKE. Indirect HPKE is Key Encryption. As shown above, headers can be used in KE without dependency issues (4 < 13). And the way I would expect it to work in API is that one first creates multi-recipient JOSE object and then can add recipients (which could be symmetric, EC DH, HPKE, RSA or other asymmetric keys), and then finalize the object (specifying things like plaintext and JWE AAD) to get the resulting JWE. Direct HPKE is completely new mode, that does not currently exist in JWE, because none of the current 5 JWE modes is suitable for direct HPKE. The step numbers above are inapplicable for such mode. One needs to define how that mode works. Rough outline of the simplest way to do that is (for encryption): - "enc:dir" is required to go into protected headers. - Perform steps 11 through 14 from stock JWE. - Invoke algorithm "direct encryption" operation, with M and Additional Authenticated Data as inputs. - Perform steps 10 and 16 through 19 from stock JWE. (Step 10 was moved after encryption is to allow direct encryption operation to use JWE Initialization Vector as output.) It is trivial to fit direct HPKE to this: - (key to be used) -> HPKE pkR - (ciphersuite) -> HPKE kdf_id. - (ciphersuite) -> HPKE aead_id. - (empty) -> HPKE info - Additional Authenticated Data -> HPKE aad - M -> HPKE pt - HPKE enc -> JWE Encrypted Key - (empty) -> JWE Initialization Vector - HPKE ct -> JWE Ciphertext - (empty) -> JWE Authentication Tag The inputs and most of outputs (everything except JWE Encrypted Key) of this operation are nonsense for indirect HPKE, so there is no reason to try to "align" the two (and just wind up making things more complex instead getting any actual alignment). (Things are very different in COSE, where direct and indirect HPKE are unified, which impiles any and all alignment.) -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
