On Thu, Mar 21, 2024 at 06:29:35AM +0000, lgl island-resort.com wrote: > Maybe take a closer look at the lamps attack details. The attacker > doesn’t come to know the CEK (same as in -25). It’s a bit subtle and > may not always succeed, but it's enough of an opening that our general > purpose work here in the IETF should close it off.
And it is not just problem for COSE-HPKE, it is problem for any other- type algorithm. Looking at the COSE registry and adding HPKE, those are: 1) A*CTR and A*CBC ([-65534,-65529]) 2) RSAES-OAEP* ([-42,-40]) 3) ECDH-xS+A*KW ([-34,-29]) 4) A*KW ([-5,-3]) 5) A*GCM, AES-CCM-* and ChaCha20/Poly1305 ([1,3], [10,13], 24 and [30,33]) 6) HPKE-* (???) Looking at these in turn and how those could be fixed to bind the algorithm above: 1) These algorithms are highly radioactive / third rail, and are the root of all this mess. Only systems that absolutely need these should implement, and even then in separate implementation that does not interact with the normal one. 2) Really annoying one, difficult to do anything about. These are not aad-capable, nor is there any obvious way to make aad-capable versions. 3) Chaining next-next algorithm into KDF step would work. These will get redone if fully-specified algorithms also applies to encryption. 4) Another annoying case. Not aad-capable, and there is no obvious aad-capable algorithm suitable for key wrapping based on AES. 5) These are not good for key wrapping, unless decomposed with direct KDF. One could add direct KDFs with next-next algorithm. 6) Aad-capable, could add next-algorithm information into aad. COSE is clearly meant to withstand the attack, in order to have Key Transport -type algorithms like 2). Unfortunately, adding the algorithms in 1) broke that. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
