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.
LL On Mar 20, 2024, at 8:26 PM, AJITOMI Daisuke <[email protected]> wrote: I don’t think that logic makes sense. Two-layer COSE-HPKE is vulnerable to the lamps attack. Sorry, I can't understand this logic. Why is the two-layer COSE-HPKE vulnerable to the lamps attack? As you mentioned as follows, > Anyway, in COSE-HPKE key encryption, the key encryption at layer1 is > protected by HPKE and is not affected by the lamps attack. Yes, that’s true. In particular you can’t change the algorithm ID for the AEAD inside HPKE to a non-AEAD. Such a change will be detected and blocked. in COSE-HPKE, CEK is protected by HPKE at layer1. Under the situation where the attackers cannot know the CEKs, cannot intercept the key derivation between senders and recipients and cannot change the CEKs (this situation is guaranteed by HPKE at layer1), what exactly is the problem? Could you tell me specific attack methods or threats? Daisuke 2024年3月21日(木) 2:27 lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>>: On Mar 19, 2024, at 5:43 PM, AJITOMI Daisuke <[email protected]<mailto:[email protected]>> wrote: Hi Laurence, Two-layer COSE-HPKE is structurally the same as -25. If we take out COSE_KDF_Context and don’t provide an equivalent we are going backwards. It's not correct. Two-layer COSE-HPKE is not similar to -25, but -29. To illustrate using HPKE, in direct key agreement (-25, etc.), KEM and KDF are done at layer1, and AEAD is done at layer0. On the other hand, in COSE-HPKE key encryption, KEM, KDF, and AEAD all are done at layer1 for CEK encryption. This is the same as Key Agreement with Key Wrap (-29, etc.). Well, yes, kinda-sorta, but in a way that doesn’t matter for the discussion at hand. The important part is that next_alg provides the necessary protection for both -25 and COSE-HPKE Key Encryption (aka 2-layer COSE). They are the same in that regard. As you mentioned, next_alg is not a solution for -29. From my understanding, next_alg makes sense primarily for direct key agreement and is not related to COSE-HPKE. I don’t think that logic makes sense. Two-layer COSE-HPKE is vulnerable to the lamps attack. (and we can probably have a next_next_alg or such to fix -29). Anyway, in COSE-HPKE key encryption, the key encryption at layer1 is protected by HPKE and is not affected by the lamps attack. Yes, that’s true. In particular you can’t change the algorithm ID for the AEAD inside HPKE to a non-AEAD. Such a change will be detected and blocked. The discussion about the keys used at layer0 is independent of layer1, and in my opinion, does not need to be considered in COSE-HPKE draft, regardless of whether non-AEAD algs can be used at layer0. Not sure why you mention “keys used at layer 0”. What matters is that the algorithm ID at layer 0 is protected. It must always be protected no matter what type of COSE or HPKE or CMS or JOSE we are considering. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
