One way to assure yourself of the attack is to implement it. You don't need HPKE to convince yourself of it, at any point where you decrypt a content encryption key, and then apply it to the enc structure at layer 0, and you choose the algorithm from the layer 0 header or from external information... Imagine the attacker has changed this, or a service has misconfigured the algorithm that will be used.
The result of AES-CBC will be garbled, but it will contain information about the CEK. The solution to the attack is to cause decryption of the CEK to fail when the next alg changes, or to cause a different CEK to be derived if the next algorithm changes. OS On Sat, Mar 23, 2024, 9:35 AM AJITOMI Daisuke <[email protected]> wrote: > Laurence, sorry, I just want to understand why next_alg can protect > against the lamps attack to two-layer COSE-HPKE. > > Unfortunately, currently no algorithm that takes a key (as opposed to >> giving a key) can protect the algorithm at next layer. > > > > Ilari, I interpreted what you said as meaning that there is no algorithm > for encrypting (wrapping) the layer0 keys at layer1, including COSE-HPKE, > that can prevent the lamps attack. Am I mistaken? > If I was mistaken, could you tell me how the next_alg can specifically > protect against the lamps attack to the algorithms that takes a key? > > > Could you tell me specific attack methods or threats? > > This is the question I posted previously, and I found a threat myself. I > thought there might be a slight possibility for a lamps attack to succeed > if the victim can accept both A128CBC and A128GCM as content encryption > algorithms at Layer0 and uses the same CEK for both algorithms. However, > the next_alg is only bound to the key wrapping the CEK and cannot affect > the CEK itself. Therefore, it doesn't seem like a meaningful measure since > it can't limit the reuse of the CEK. > > Am I missing something? > > Daisuke > > 2024年3月23日(土) 7:01 lgl island-resort.com <[email protected]>: > >> >> On Mar 22, 2024, at 6:44 AM, AJITOMI Daisuke <[email protected]> wrote: >> >> Unfortunately, currently no algorithm that takes a key (as opposed to >>> giving a key) can protect the algorithm at next layer. >> >> >> Ilari is talking about algorithms like AES Key Wrap, not what HPKE Seal() >> provides and not ECDSA. >> >> I agree. The content_encryption_alg (next_alg) cannot be a countermeasure >> to the lamps attack on KAwKW(-29, etc.) and two-layer COSE-HPKE. >> >> >> next_alg (or better content_encryption_algorithm can be used to protect >> COSE-HPKE and probably also protect -29 if applied correctly. >> >> Of course, it is effective against the attack on direct KeyAgreement >> (-25, etc.) and I think it's much better than COSE_KDF_Context. >> >> I believe what we should consider is only whether non-AEAD algs should be >> prohibited at layer0 or not. >> I think it would be better to be prohibited if possible. >> >> >> Daisuke, it looks to me that you are the only one that continues to argue >> this. Also, nothing you’ve said has created any doubts for me. >> Respectfully, I’m not going to respond to your arguments any more unless >> something very substantially changes. >> >> LL >> >> _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
