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

[Ilari Liusvaara <[e-mail]>]

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).


> 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.


> However, the problem is that COSE explicitly allows aad-incapable key
> management algorithms (e.g., Key Transport or the whole section 5.4
> stuff). And often there isn't even hacks around that.
> 
> You are talking about 6.1.1 and 6.2 from 9053 used with the non-AEADs
> in 5.4, right?  The others in section 6 of 9053 have a KDF, so they
> are OK (except for -29 which gets tripped up by key wrap).

Out of 9053, Mainly section 6.2.

But also RFC8230 section 3.


AES-GCM (or Chacha20-Poly1305) is not good for Key Wrap. However,
combining those with Direct Key with KDF (9053 section 6.1.2.) makes a
decent key wrap.


> I suppose errata might be issued with additional security
> considerations.

Yes. This whole mess started from insufficient security considerations.




-Ilari