> On Jun 21, 2025, at 11:07 AM, Ilari Liusvaara <[email protected]>
> wrote:
>
> On Sat, Jun 21, 2025 at 06:49:56AM +0900, AJITOMI Daisuke wrote:
>> Hi Hannes, Mike, all,
>>
>> Over the past year, I haven’t been able to contribute to the revisions of
>> the specification despite being a co-author. However, I’ve reviewed the
>> latest content again and believe there are no major issues.
>
> The COSE_MAC stuff seems very broken, at least in base mode. What is
> to prevent an attacker that has victim public key from choosing the
> message, MACing it with random key, and then encrypting the key to
> recipient?
>
> That would not work in auth mode, but it is not supported (and it
> would still be a lot weaker than proper signatures).
I filed an issue so we don’t forget this:
https://github.com/cose-wg/HPKE/issues/81
>> I’d feel a lot better about the “yes, let’s publish” if there was some
>>> comment and confirmation that next_layer_alg in Recipient_structure
>>> [3.1.2.1] secures the bulk encryption algorithm ID well enough that a
>>> non-AEAD can be used. I think it does, but we should have a little
>>> consensus on this.
>>
>> At one point, I misunderstood your proposal, but I’m now confident that the
>> current approach is appropriate.
>
> If an attacker changes the next layer algorithm from AE(AD) to non-AE,
> the aad will not match, which causes decryption failure with very high
> probability.
You’ve confirmed that next_layer_alg does the main job of defending against the
lamps attack.
> Next_layer_alg does not help if the next layer algorithm is already
> non-AE, but that is a Bad Idea anyway.
Right. This is not to enforce against bad choices for the bulk content
encryption. We can make recommendations, but that should be done elsewhere.
> Next_layer_alg also does not detect replacing bulk encryption with
> key wrap, but getting a valid key wrap seems very hard. Reusing other
> key wraps does not work, because that needs KEK, which would
> compromise the message anyway.
To clarify, if an attacker replaced AES-128-GCM with A128KW, next_layer_alg
would cause it to be detected.
If a protocol designer created a three layer COSE encryption (e.g.,
HPKE-key-wrap-AES), next_layer_alg would secure the ID of the key wrap, but not
the AES. This is more a problem with the three layer design than
next_layer_alg, so no problem here either.
So, you’ve thought through the next_layer_alg design some and haven’t found a
problem with it, right?. This makes me feel more confident. Thank you.
LL
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
