On Thu, Nov 09, 2023 at 12:12:49PM +0000, lgl island-resort.com wrote: > > On Nov 9, 2023, at 12:36 PM, Ilari Liusvaara > <[email protected]<mailto:[email protected]>> wrote: > > We could make two-layer COSE-HPKE take care of this, but we’d have > user Context Info Structure with COSE-HPKE, which is currently not > the plan, or find some other way to mix in the identifier for the > bulk encryption algorithm. I think it could be in a protected > parameter. > > For two-layer COSE-HPKE, next_alg header would work. Unfortunately, it > is not a good solution because it will not work with the usual key wrap > modes, because those are not AEAD. > > It will work for two-layer *COSE-HPKE* because aad and/or info inputs > to Seal() can be used. > > It won’t work for two-layer methods in 9053 like -29 because of key > wrap. > > It will work for two-layer methods in 9052 like -25, but it is > redundant because Context Info Structure is required anyway. > > Right?
Right (modulo only aad input to Seal() being available). And the second point above (won't work with likes of -29) is the major issue. Pushing the KDF to other side would work with both COSE-HPKE and -29 (and all the other similar things as well). Also, I have an idea about how to safely address usecases that led to the dangerous A*CTR/A*CBC modes. However, it turns out to involve a bit of nontrivial crypto (because one wants collision resistant tags). Related presentation in CFRG@IETF118: "How Subtle AEAD Differences can Impact Protocol Security". -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
