> > ... 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. >
I've realized that this assumption is quite absurd. I'm starting to think that, as I originally thought, we don't have to worry about the lamps attack in the context of two-layer COSE-HPKE. Anyway, I will stop discussing this topic on the mailing list. Daisuke 2024年3月23日(土) 14:34 AJITOMI Daisuke <[email protected]>: > 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
