On Jun 21, 2025, at 11:07 AM, Ilari Liusvaara [email protected] wrote: > > 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 [cose-mac-github] to be sure we thought about this. I’ve thought about it and agree with Ilari. [cose-hpke-mac] is a really bad example. No one should ever use because it is insecure. Two options for the document: 1) Remove the example entirely 2) Leave the example, and explicitly warn in the example text that it is entirely insecure and is only there for the sake of completeness to show what can be done with COSE-HPKE. I think this is so insecure that it needs an up front warning, not just a few words in the security considerations section. Why is this so bad — it would seem to provide integrity protection and maybe authentication but provides neither. COSE-HPKE is used to encrypt a key being sent to the recipient. That key is used for integrity protection and maybe authentication. The problem is that the sender can choose the key so they can pick any key and MAC any message. No security services are provided to the recipient. The problem here is that HPKE is used in base mode. It is only providing encryption. As Ilari says, this construct would be OK if HPKE was used in auth mode, but the draft doesn’t support auth mode. I prefer option 1). When we make the cose-hpke-auth standard, we can put the example in. LL [cose-hpke-mac]: https://www.ietf.org/archive/id/draft-ietf-cose-hpke-15.html#name-cose_mac [cose-mac-github]: https://github.com/cose-wg/HPKE/issues/81 _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
