Subject: [jose] PBES2-HS256+A256KW or PBES2-HS512+A256KW?

From: Mike Jones <[email-masked]>
Date: Thu, 18 Jul 2013 21:26:42 +0000

Currently JWA defines two password-based key encryption algorithms:
               PBES2-HS256+A128KW
               PBES2-HS256+A256KW

I was surprised that when the AES key size was increased from 128 to 256, the HMAC key size was not also increased from 256 to 512.  Sean, Matt had told me that this used to be the case in his individual draft, but that you had requested that HMAC SHA-256 be used for both algorithms.

If for no other reasons than symmetry, I'm curious why.  For instance, in McGrew's AES-CBC-HMAC-SHA2 draft, these pairings are made:
               128 bit AES with 256 bit HMAC
               192 bit AES with 384 bit HMAC
               256 bit AES with 512 bit HMAC
Sean, why aren't we doing the same for password-based encryption?

                                                            Thanks,
                                                            -- Mike

---

From: Sean Turner <[email-masked]>
Date: Fri, 26 Jul 2013 15:27:25 +0200

Mike,

Apologies for taking too long to get back to this.

The -01 version used HMAC-512 untruncated.  To me that didn't make much 
sense.  You're getting some level of security but you're carrying a lot 
of extra bytes.  Using either a truncated HMAC-512 as Dave's draft does 
or HMAC-SHA-256 lines up the bits of security provided by the algs.  I 
guess the embedded question is whether we should align the 3.

spt

On 7/18/13 11:26 PM, Mike Jones wrote:
> I was surprised that when the AES key size was increased from 128 to
> 256, the HMAC key size was not also increased from 256 to 512. Sean,
> Matt had told me that this used to be the case in his individual draft,
> but that you had requested that HMAC SHA-256 be used for both algorithms.
>
> If for no other reasons than symmetry, I’m curious why.  For instance,
> in McGrew’s AES-CBC-HMAC-SHA2 draft, these pairings are made:
>
> Sean, why aren’t we doing the same for password-based encryption?
>
>                                                              Thanks,
>
>                                                              -- Mike
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 31 Jul 2013 15:43:11 +0000

Hi Sean,

HMAC SHA-512 would be used as the pseudo-random function (PDF) by PBKDF2.  The key output size would still be 256 bits when used with A256KW, so truncation would occur as part of the key generation (see the statement about the dkLen values in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-14#section-4.9).  The encrypted key size is whatever the size of the original Content Encryption Key (CEK) is, plus the A256KW overhead.  So you're not carrying extra bytes on the wire.  (You are computing extra bytes as intermediate results during the password-based encryption computation, but given that it's a *good thing* for this to be computationally intensive, that's probably not a bad thing.)

Am I missing something here?  If not, I think we should align with what McGrew has done and pair the use HMAC SHA-512 with the use of 256 bit AES keys (and pair HMAC SHA-384 with the use of 192 bit AES keys).  For one thing, this would mean that we would have algorithm identifiers using a diversity of hash functions.

I won't lose sleep over this either way, but my sense of symmetry tells me that it would be nice to match the algorithms in the way that McGrew did.

Thoughts?

				-- Mike

-----Original Message-----
From: Sean Turner [mailto:[email-masked]] 
Sent: Friday, July 26, 2013 6:27 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: PBES2-HS256+A256KW or PBES2-HS512+A256KW?

Mike,

The -01 version used HMAC-512 untruncated.  To me that didn't make much sense.  You're getting some level of security but you're carrying a lot of extra bytes.  Using either a truncated HMAC-512 as Dave's draft does or HMAC-SHA-256 lines up the bits of security provided by the algs.  I guess the embedded question is whether we should align the 3.

spt

On 7/18/13 11:26 PM, Mike Jones wrote:
> If for no other reasons than symmetry, I'm curious why.  For instance,
> in McGrew's AES-CBC-HMAC-SHA2 draft, these pairings are made:
>