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

[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
>>
>