Message info
 
To:John Bradley From:Brian Campbell Subject:Re: [jose] Understanding the motivation for Key Derivation? Date:Thu, 5 Apr 2012 15:05:39 -0600
 

Is it worth considering (I'm guessing the answer is no but what the
heck) going the other direction and making the separate integrity
check required regardless of the encryption algorithm? It would mean,
when using GCM anyway, larger JWEs and also not utilizing the inherent
integrity checks provided by that class of algorithm. But it would
also mean a cleaner encapsulation of the algorithm from the JWE
perspective and less conditional logic in JWE.

Perhaps that suggestion might be more realistic if the separate
integrity check was required but then also allowing the "none" option
from the list of JWS cryptographic algorithms to be used for
integrity in addition to the HMAC ones. And lastly, define some kind
of mapping or requirements between the "enc" algo used and allowed or
required "int" algorithms (i.e. "A256GCM" and "A128GCM" are the only
ones that can be used with "none"). That would provide integrity
protections, simplify the treatment of the various "enc" algorithms in
JWT (no more conditionals on the algorithm), avoid defining composite
algorithm identifiers (like A128CBC-H256), and also allow the AEAD to
use their own integrity protections.

Just some thoughts...

On Thu, Apr 5, 2012 at 10:10 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Then we should look at including the header as the additional data for GCM.
>
> I will have a look at it, and make a proposal for some text, unless someone else is volunteering?
>
> John B.
>
> On 2012-04-05, at 1:05 PM, Jim Schaad wrote:
>
>> Ok - I see you problem.
>>
>> Yes, in JWE the headers are not encrypted.
>> GCM provides integrity over both the encrypted content and the additional
>> data fields (hence the difference between AD (authenticated Data) and
>> AEAD(Authenticated Data with Additional Data).
>>
>> All AEAD algorithms provide for the ability to have data which is not part
>> of the encrypted data be included in the authenticated data. In fact AEAD
>> algorithms can be used as MAC algorithms in many cases by simply having an
>> empty string for the encrypted data (it depends in part on the internal
>> construction of the encrypted data stream). I believe we verified that this
>> was a true statement for GCM at the last IETF meeting (in a hallway
>> conversation).
>>
>> Jim
>>
>>
>>> -----Original Message-----
>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>>> Sent: Thursday, April 05, 2012 8:45 AM
>>> To: Jim Schaad
>>> Cc: 'Matt Miller'; 'Brian Campbell'; jose@ietf.org
>>> Subject: Re: [jose] Understanding the motivation for Key Derivation?
>>>
>>> In JWE the headers are not encrypted.
>>>
>>> GCM provides integrity only over the encrypted content.
>>>
>>> In the composite AES-CBC + HMAC the integrity is calculated over both the
>>> Header and the encrypted content.
>>>
>>> The advantage of not using a AEAD algorithm is that the composite can be
>>> more JOSE aware.
>>>
>>> I can't rule out having missed something thats why we review these
>> things:)
>>>
>>> John B.
>>> On 2012-04-05, at 12:28 PM, Jim Schaad wrote:
>>>
>>>> <no hat>
>>>>
>>>> John,
>>>>
>>>> I am at a loss, why do you believe that a new AEAD algorithm would not
>>>> protect the headers?
>>>>
>>>> Jim
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
>>> Of
>>>>> John Bradley
>>>>> Sent: Thursday, April 05, 2012 7:28 AM
>>>>> To: Matt Miller
>>>>> Cc: Brian Campbell; jose@ietf.org
>>>>> Subject: Re: [jose] Understanding the motivation for Key Derivation?
>>>>>
>>>>> A couple of observations.
>>>>>
>>>>> The current proposal provides integrity over the header, a new AEAD
>> alg
>>>>> doesn't do that.
>>>>> Low level crypto is a challenge. Re-using standard underlying
>> algorithms
>>>> like
>>>>> HMAC and AES-CBC allow for JS and other libs to call standard lower
>> level
>>>>> crypto functions.
>>>>>
>>>>> I am not against having another AEAD alg, but want to help people
>>>>> understand the current design choice.
>>>>>
>>>>> John B.
>>>>> On 2012-04-05, at 9:49 AM, Matt Miller wrote:
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Another way around the conditional in application-space is to define
>> an
>>>>> AEAD algorithm composed of an encryption and hashing function. This
>>>>> seems like a reasonable place to start looking at one: <
>>>>> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha1 >.
>>>>>>
>>>>>> On Apr 4, 2012, at 17:42, John Bradley wrote:
>>>>>>
>>>>>>> The use of a single key across two functions is one of things that is
>>>> not
>>>>> provably without problems.
>>>>>>>
>>>>>>> I agree that from an implementers point of view one key is simpler.
>>>>>>>
>>>>>>> There is a related-key attack that using the same key would enable.
>>>> This
>>>>> can be combined with differential and linear attacks on symmetric key
>>>>> cyphers.
>>>>>>>
>>>>>>> Generally this can be thought of as a bad thing.
>>>>>>>
>>>>>>> What is certain is that it increases the possible attack surface,
>> and
>>>> if the is
>>>>> a problem discovered as we have seen with AES-CBC it is going to be
>> hard
>>>> to
>>>>> change later.
>>>>>>>
>>>>>>> We need key derivation anyway for ECDH-ES to produce a key of the
>>>>> correct bit length.
>>>>>>>
>>>>>>> Doing key derivation on CMK is the theoretically proper way to do it.
>>>>>>> Making a simplification might bite us in the future.
>>>>>>>
>>>>>>> I suppose one way to get around the conditional application argument
>>> is
>>>>> to always use it to produce the CEK even with AEAD algorithms.
>>>>>>>
>>>>>>> Regards
>>>>>>> John B.
>>>>>>>
>>>>>>> On 2012-04-04, at 7:40 PM, Brian Campbell wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I was hoping someone could help me (hopefully it's not just me!)
>>>>>>>> understand the reasons for the introduction of the key derivation
>>>>>>>> stuff* into JWE draft -01?
>>>>>>>>
>>>>>>>> I understand that it's there to derive the two keys, CEK and CIK,
>>>>>>>> from the CMK and that it is to be done when a non-AEAD algorithm is
>>>>>>>> used to encrypt the content. But what is the value of deriving the
>>>>>>>> two keys as apposed to using the CMK for both encryption and
>>>> integrity?
>>>>>>>>
>>>>>>>> Perhaps naively I assumed that using the CMK for both would be
>>>>>>>> sufficient. It's randomly generated and used only for the one JWE.
>>>>>>>> It's not clear to me what benefit is provided by the additional
>>>>>>>> complexity of the derivation function as well as its conditional
>>>>>>>> application (and the potential interoperability problems that come
>>>>>>>> with such complexity). I assume there's some security benefit? But I
>>>>>>>> can't see what it is.
>>>>>>>>
>>>>>>>> Any help would be appreciated.
>>>>>>>> Thanks,
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> *
>>>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se
>>>>>>>> ction-7
>>>>>>>> which is referenced by
>>>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se
>>>>>>>> ction-5 and
>>>>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#se
>>>>>>>> ction-6 _______________________________________________
>>>>>>>> jose mailing list
>>>>>>>> jose@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jose mailing list
>>>>>>> jose@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>>
>>>>>>
>>>>>> - - m&m
>>>>>>
>>>>>> Matt Miller - <mamille2@cisco.com>
>>>>>> Cisco Systems, Inc.
>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
>>>>>> Comment: GPGTools - http://gpgtools.org
>>>>>>
>>>>>>
>>>>>
>>> iQEcBAEBAgAGBQJPfZT4AAoJEJq6Ou0cgrSP00UIAMxGZw0K50RJPD4JWRvVq
>>>>> zQj
>>>>>>
>>>>>
>>> YFYN5dpM4qG+SLll53BesKPNqSF79L5M5yp9gLW7lVTBdDGd5+k7uU+qn7rDR
>>>>> 8kx
>>>>>>
>>>>>
>>> c4m46Wvffbevl6KRFg+vbBA3JZz/S41/mc6Vd3hZ9ib4+1Na66Vzpqp6qOnVDvL
>>>>> y
>>>>>>
>>>>>
>>> LgMqohVeXACHsxVL8BpXqDz336slFBS4gP67cI9Yail0ZUNsZAm+NcoNhnbqLlb
>>>>> +
>>>>>>
>>>>>
>>> ottj9ZpLP8gnYaCus0sM2fshgWapcc4ZN6QbA9F105zEdrNwCDX5ht68Zkma7fb
>>>>> Y
>>>>>>
>>>>>
>>> LgFBqvqB2PtRu7SV2QGbNmaG1BGRZ9V3mKXZL/ssryLaOSVrCB5GdNHprlDG
>>>>> z/I=
>>>>>> =174E
>>>>>> -----END PGP SIGNATURE-----
>>>>
>>>>
>>
>>
>
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose