On Thu, Jan 25, 2024 at 07:26:21AM -0600, Orie Steele wrote: > I don't understand your comment about the space in "some string" preventing > cross mode attacks, and it's not clear which header you are placing the enc > (encryption algorithm) value in, but I assume it is the top level header.
The standard JWE authenticated data construction can never generate output with a space character (only alphanumerics, dash, underscore and full stop). Therefore if one mode uses standard JWE authenticated data construction, and another mode uses aad that has space in it, then it is not possible for attacker to transplant ciphertexts between the modes. And yes, if "enc" is present, it goes to top-level headers, just like in JWE currently. (Comparing to COSE-HPKE: Such transplanting is blocked by the enc_structure context.) > If that's true, that header is marked protected, but your proposal doesn't > protect it. JWE is designed to be able to withstand unprotected "enc". In JSON serializations, it is even allowed to put "enc" in unprotected headers! The attack presented in LAMPS slides does not work against JWE (because "enc" must be AEAD). However, this does not mean one does not need to be careful with changes, lest one enables such attacks (happened with COSE! Oops.) > If you just use that protected header value as the aad, then it will have > protection. In Key Encryption? If so, that does not work: - Causes severe problems with implementations. - Allows attacker to transplant ciphertexts between modes. > It seems weird to concatenate strings when you have a json object that can > clearly identify them. I don't think that json object is intended to be used that way (JWE section 5.1, step 4). -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
