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

[Matt Miller <[e-mail]>]

On Apr 15, 2013, at 9:25 AM, Richard Barnes <[e-mail]>
 wrote:

> On Sun, Apr 14, 2013 at 9:55 PM, Manger, James H <
> [e-mail]> wrote:
> 
>> 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
>> 
>> 
> 
> At the same time, this attribute should be optional, since I think there
> are use cases where the CMK is not entirely ephemeral.  For example, I
> think the current XMPP e2e document uses it as a session key rather than an
> individual message key, so you wouldn't want to limit the key to a single
> JWE.
> 

XMPP e2e has both a session key and a per-message key. The per-message key is protected by the session key.

That said, I also think Option 2 or 2b makes the most sense.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.