> On Mar 24, 2024, at 2:51 AM, Ilari Liusvaara <[email protected]> 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 <[email protected]> >> 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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
