Re: [COSE] [jose] HPKE PartyU / PartyV

["lgl island-resort.com" <[e-mail]>]

> On Mar 24, 2024, at 2:51 AM, Ilari Liusvaara <[e-mail]> wrote:
> 
> On Sat, Mar 23, 2024 at 08:37:58PM +0000, lgl island-resort.com wrote:
>> 
>> On Mar 23, 2024, at 10:13 AM, Ilari Liusvaara <[e-mail]> wrote:
>> 
>> _If_ key management algorithm is aad-capable, adding next_alg to aad is
>> an easy way to make decryption fail if attacker alters algorithms.
>> 
>> COSE -25 and for COSE-HPKE key management is aad-capable. With a
>> little extra work I think content_encryption_algorithm (formerly
>> next_alg) can work for COSE -29.
> 
> Sure -29 can be hacked to work. And fully-specified-encryption would
> redo it anyway. The main problem is Key Wrap and Key Transport.
> 
> And next_alg and content_encryption_algorithm are not the same thing.
> next_alg is the algorithm with what the unwrapped key will be used with,
> while content_encryption_algorithm can be something else if there is
> intermediate step (even if I do not know why anyone would do that).

My thought is that content_encryption_algorithm is the COSE algorithm ID for the next *COSE* layer.


>> I’m starting to think about a new draft to define the -29 replacement.
>> Probably not a large document. It would not use COSE_KDF_Context. It
>> would use a new Enc_structure with content_encryption_algorithm.
> 
> There should still be something close to COSE_KDF_Context, because it
> is driven by ECDH (or KEM), and thus there should be KDF step.
> 
> 
>> It could define a -25 replacement too, one without COSE_KDF_Context.
> 
> Uh, the whole purpose of -25 is to have ECDH driving a KDF.

Yes, still must have a KDF and section 5.1 applies, but the “info” or "context information” input to the KDF would be a Recipient_structure like that proposed by Ori, not the COSE_KDF_Context from section 5.2.

LL