On Sat, Oct 11, 2025 at 08:32:40AM -0500, Orie wrote: > > Make a new key type if you want to have keys that have a different set of > security properties (such as being explicitly used with multiple > algorithms).
Do not even need a new key type for that, since public and private keys are both byte strings. > If you want to go this route, I would lean into the idea that you can't > actually enforce any algorithm checking at the key side, and just say that > the attacker controlling the algorithm in the message is not a concern for > kems. > (I don't agree with this, but that's what the argument appears to be to me, > please correct me if I am wrong). JOSE already mandates checking that algorithm is consistent with key (and omitting such checking usually leads to internal errors, crashes or critical CVEs[1]). Here the attacker can only control if the wrapping step is done or not. And this affects the key used for next step. And with COSE, it is not wrap absent/present, it is wrap optional/ mandatory, because AE(AD) on layer1 acts as key wrap without influencing other algorithms. Now, if algorithms consistent with key could interact harmfully, this would be a serious problem (this is actually the reason for the "single purpose" recommendations). > In JOSE and COSE, the algorithm on security objects is controlled by the > attacker. > Without requiring the algorithm to be on the key, you will need to "try it > out" to see if it works. > As soon as you do that, you are doing work for the attacker... The system > may still fail closed, but you've already done more work than you needed to. I can't think of anything useful attacker could do. Removing unwrap step would cause decryption failure (which is considerably heavier than unwrap failure), but attacker can do that just by changing the message tag. Now, with some more poorly designed stuff, there absolutely could be problems (see above). [1] IIRC, there was one case where trying to encrypt with signature key caused the whole system to BSOD (kernel-mode fault). -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
