On Thu, Jul 25, 2024 at 08:03:19PM +0000, lgl island-resort.com wrote: > > > On Jul 25, 2024, at 12:26 PM, Michael Jones <[email protected]> > wrote: > > > I obviously fully support dealing with cross-mode attacks in COSE. > > But the Fully-Specified Algorithms draft looks like it’s not going > > a place to do this. > > Right. Fully-specified won’t fix cross-mode. But we could create only > one new alg ID to identify both behavior changes rather than fanning > out alg IDs.
Due to how COSE is designed, there are really only two possible ways to fix the LAMPS attack (assuming not implementing CBC/CTR is not an option): - Add optinal KDF step to layer. - Add layer that performs KDF. ... The first is much simpler for implementations. Adding any fully-specified algorithm will not fix it, because it would still leave all the other key managment stuff, some of which does not even have any obvious way to fix the issue. Alternatively, adding an algorithm with KDF would fundamentally polymorphic. And I would use the following context for the KDF: - depth (uint/null) - algorithm (int/tstr) - key/iv flag (bool) - output length (uint) - salt (bstr/null) Generating IV both saves message bytes and is cryptographically safer. TLS 1.3 and HPKE both generate the IV. There is one TLS 1.2 attack that exploits lack of IV generation. Right now, there is no way to safely do one-layer Direct Encryption (right now, one has to use Direct Key with KDF as second layer). KDF with salt would fix that. And I would define the header triggering the KDF mechanism to take an int, which is right now fixed to 0. We might want to add another KDF even without SHA-2 getting broken. E.g., KDF based on SHA-3 and friends. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
