On Mon, Jun 17, 2024 at 06:04:55PM +0000, lgl island-resort.com wrote: > Hi Hannes, > > 1) Data structure design > I’d like to provide something that is much simpler than the info > struct that can do everything it can if needed. I think the way > to do this is by allowing COSE headers to get in the mix rather > than the bunch of awkward fixed fields in the info struct that > are NULL most of the time.
Applications that need identities can use external aad field (or protected headers if that is not "exciting" enough). > Despite having info struct, COSE -29 and multi-recipient COSE-HPKE > weren’t safe from the lamps attack. Info struct is no magic bullet, > not even with every field filled in. COSE missed documenting a critical security requirement, and then somebody broke it. Oops. If lamps attack is actually possible depends on implementation. Implementations that do not implement unauthenticated encryption are immune. > I’d like to proceed with the better recipient structure and our best > recommendation for security, more or less what we came up with in San > Francisco. It will be much better than already-published CMS and COSE. > Better because we’ve done more thinking and because we’ve made fixes. > We will also provide all the facilities that info struct provides > (in a different form) so we’ll not be going backwards. I think there is a lot to document about security aspects of COSE. And that includes how to prevent lamps attack (don't implement unauthenticated encryption). > I’m not a cryptographer either, but I’m pretty confident by the > circumstantial evidence, by my own thinking and by the discussions > we’ve had. The circumstantial evidence is that we haven’t turned out > any literature or on-line discussion discussing how to use info > struct. It’s been published many years. JOSE has used it. The > explanation for much of the text in NIST SP 800-56A Appendix B is > re-use of keys and bad RNGs. Paul is of course going to say what he > said by default. I think the question I’d ask him is this: “what’s the > worst attack assuming a good RNG and no key re-use”. Did he know about > the lamps attack? Note that the "key re-use" _can_ happen in COSE (but not in JOSE). And the identity stuff in COSE is adequate for dealing with that case. And it will not happen with HPKE or native KEMs. > I also find it interesting that no one is excited about the fact that > COSE -29 is a published IETF standard with a known vulnerability. > There’s no effort to fix it. There’s no notification posted. It’s not > in any vulnerability database. Given the design of COSE (and JOSE), there are only two realistic ways to deal with the lamps attack: - Prohibit unauthenticated encryption * JOSE does this. * COSE just missed explicitly stating this? - Add key derivation step before encryption. * The CMS fix. * Also useful with direct encryption. (If an implementation does not support unauthenticated encryption, it is not vulnerable to lamps attack.) > I want to fix COSE -29 with the same fix I’m proposing here for > COSE-HPKE<https://github.com/cose-wg/HPKE/pull/58/files>. Unfortunately looks like we are not touching -29. And then that context structure lacks layer depth info (which the present encryption context does have). -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
