Re: [Cfrg] [jose] GCM nonce reuse question

["Manger, James H" <[e-mail]>]

I think there are more options for handling multiple recipients of AEAD-secured content:


Option 3: Put all per-recipient info into one header; keep this header under the AEAD integrity check; have one nonce.
  COST: All recipients need to be known (and their key exchange info created) before the AEAD algorithm is applied.
  COST: The JWE JSON header structure needs to be adjusted (eg to have an array of recipient info) so it is not backward compatible with current drafts.
  COST: Doesn't help use cases where one recipient forwards an AEAD-secured message on to a new recipient (eg an XMPP system receives a message secured for a user and re-secures it for a specific device of that user). Changing recipients requires reapplying the AEAD operations.
  COST: Each recipient needs to see key exchange info of all recipients (privacy impact?).
  POSSIBLE-BENEFIT: Recipients, key exchanges, parameters, and content is secured as a complete unit.
 

Option 2b: Remove per-recipient info from AEAD integrity check; but add AEAD details to each key exchange. For instance, info about an AEAD operation (alg id, key id etc) potentially even including the whole ciphertext is used as the "label" for the RSAES-OAEP-ENCRYPT operation that encrypts the AEAD secret key for a recipient.
  BENEFIT: The key exchange is tied to a specific AEAD operation.
  COST: Crypto is not typically done like this; uncertain as to what exact security properties you are getting. Perhaps there are some similarities to NIST Concat KDF that adds "context" to key derivation: this adds "context" about an AEAD operation to the key exchange.


I agree with Richard Barnes that the per-recipient key exchange details should be outside the AEAD operation (not covered by the AEAD integrity check). Go with option 2 or 2b.
Then, separately, we can decide which details of the AEAD operation should be bound to each key exchange: none? AEAD key length? AEAD alg id? whole AEAD header? AEAD ciphertext? other context?


--
James Manger

> ----------
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Richard Barnes
> Sent: Wednesday, 3 April 2013 4:55 AM
> … 
> The problem here is JWE, specifically the fact that the header (with
> per-recipient data) is covered by the integrity check.  If you remove
> the per-recipient data from the integrity check, then this problem goes
> away.  In that case, there is only one invocation of GCM (not one per
> recipient), so there's no problem.
> 
> So the choice that JOSE faces is from the following options:
> 
> Option 0. Outlaw GCM for multiple recipients.
>   COST: GCM
> 
> Option 1. Keep per-recipient info under integrity check, and require a
> fresh nonce for each recipient
>   COST: Removes all savings in the multiple recipient case
>   BENEFIT: Doesn't break backward compatibility with current, single-
> recipient JWE
> 
> Option 2. Remove per-recipient info from integrity check
>   COST: Breaks backward compatibility with current, single-recipient
> JWE
>   BENEFIT: Increases savings in multiple-recipient case (since no per-
> recipient integrity check value)
> 
> Option 0 is clearly not acceptable.  So basically, this is a choice
> about how much we want to let deployed code keep us from sensible
> architecture.
> 
> To me, the choice is clear.  Changing code is minor, short-term pain.
> Getting architecture wrong is major, long-term pain.  Let's do option
> (2).