Re: [COSE] [jose] HPKE PartyU / PartyV

[AJITOMI Daisuke <[e-mail]>]

>
> ... 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 <[e-mail]>:

> 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 <[e-mail]>:
>
>> 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 <[e-mail]> 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 <[e-mail]>:
>>>
>>>>
>>>> On Mar 22, 2024, at 6:44 AM, AJITOMI Daisuke <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cose
>>>
>>