On Apr 25, 2013, at 3:56 PM, Richard Barnes <[email protected]> wrote: > On Thu, Apr 25, 2013 at 3:09 PM, Mike Jones > <[email protected]>wrote: > >> Hi Russ, >> >> I agree that enabling GCM to be safely used in the multiple recipients >> case would be highly desirable. It is currently prohibited because if the >> recipients share a common key and initialization vector (IV) but use >> different AAD values, this results in the identified vulnerability. One >> possible solution that continues integrity protecting the headers but >> enables the safe use of GCM was identified off-list by John Bradley. >> >> That solution is to have each recipient always use the same key, IV, and >> AAD values. This could be accomplished by including all the header values >> in a single combined AAD value, rather than having the integrity protection >> for each recipient's headers be independent. >> >> This change could be done in a manner that doesn't affect the computation >> for the single recipients case. Given the upcoming interim JOSE meeting >> next week, and given the (understandable) strong negative reaction to the >> unusability of GCM with the current multiple recipients processing rules, >> I'll plan on quickly producing a draft -10 that changes the processing >> rules in the manner described above, so that idea can be concretely >> considered by the working group next week. >> >> Just so people are clear on the properties on the new processing rules - >> this would mean that the integrity computations for each recipients would >> no longer be independent. The only downside of this (which could be an >> upside in some ways) is that it would no longer be possible to add >> recipients over time without performing a new encryption computation with a >> new CEK and IV. >> > > As I said to John, that is not an acceptable solution because it breaks the > XMPP use case. The minimum sensible change is to remove the per-recipient > info from the integrity check. >
It is not clear to me how John's suggestion utterly breaks the XMPP use case, unless you have this alternate-reality version of XMPP-E2E you've not yet told me about (-: The current XMPP document already separates per-recipient info from the actual protected content. - m&m Matt Miller < [email protected] > Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
