> > The solution to the attack is ... to cause a different CEK to be derived > if the next algorithm changes.
Agreed. The solution to the attack is to cause decryption of the CEK to fail when > the next alg changes, .... My understanding is that this cannot be a solution to the lamps attack, because in that attack, an attacker is a legitimate sender/recipient. The attacker adds A128CBC to alg at layer0, and also adds A128CBC to next_alg at layer1, and sends a victim the ciphertext to reveal the target AEAD ciphertext block. Hmm, am I making some big misunderstanding here? The discussion has become too complicated, so I would like to pause it on the mailing list for now. I also want to organize my thoughts a bit more and write my ideas on the GitHub issue. Daisuke 2024年3月23日(土) 9:09 Orie Steele <[email protected]>: > 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
