Subject: Re: [jose] RSA-OAEP-256 Example

From: Mike Jones <[email-masked]>
Date: Wed, 11 Jun 2014 07:09:54 +0000

These updates have been incorporated in the -27 JWA draft.  Thanks again for the detailed reviews!

From: Brian Campbell [mailto:[email-masked]]
Sent: Sunday, May 11, 2014 7:42 AM
To: Mike Jones
Cc: Richer, Justin P.; Matt Miller; Antonio Sanso; Axel Nennker; [email-masked]
Subject: Re: [jose] RSA-OAEP-256 Example

Yeah, I've got a few potential updates to the table based on my experience building https://bitbucket.org/b_c/jose4j

"AESWrap" is the JCA string/transform for A128KW, A192KW and A256KW.
For ECDH-ES, the java algorithm for the key agreement part is "ECDH". AFAIK, there is nothing in the JCA that does the KDF so that part needs to be written 'from scratch' using a SHA-256 message digest. Dunno how much of that you want to try and capture in the table, maybe just "ECDH" is good. The AES key wrap part of the ECDH-ES+AxxxKW ones use same "AESWrap" as the AxxxKW above.

A128GCMKW, A192GCMKW and A256GCMKW, which aren't currently in appendix A.2 all use the same JCA algorithm as their AxxxGCM content encryption counterparts: "AES/GCM/NoPadding"

"PBKDF2WithHmacSHA256", "PBKDF2WithHmacSHA384" and "PBKDF2WithHmacSHA512" would be the SecretKeyFactory JCA algorithms for the PBKDF2 part of PBES2-HS256+A128KW, PBES2-HS384+A192KW and PBES2-HS512+A256KW respectively.  But they aren't widely implemented (only in the Java 8 provider, I think, most providers only seem to have PBKDF2WithHmacSHA1) so I ended up writing my own PBKDF2 using the corresponding HMAC-SHA2 Mac.  The encryption part is the same as the AxxxKW.

On Sat, May 10, 2014 at 3:30 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I plan to just put both strings in the table the next time edits are made.  Are there other strings or OIDS in the tables that also should be updated, based on people's implementation experiences?

                                -- Mike

-----Original Message-----
From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richer, Justin P.
Sent: Saturday, May 10, 2014 2:17 PM
To: Matt Miller
Cc: Antonio Sanso; Brian Campbell; Axel Nennker; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] RSA-OAEP-256 Example
The fact is that there's no way to get this kind of signature *without* the param spec, since it overrides the padding definition defined by the string itself. So there's not actually a single string of any kind in JCE that will do the right thing, and the appendix ought to have both pieces in it.

 -- Justin

On May 9, 2014, at 12:38 PM, Matt Miller <[email-masked]<mailto:[email-masked]>> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> As I said originally, I don't think there's a straight-forward fix
> here.  It seems to me that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"
> gets the closest to the intent here.
>
> I agree that "RSA/ECB/NOPADDING" is contradictory -- yes, you can get
> the Java code to the JOSE-specified configuration starting with that
> identifier string, but it's rather misleading without knowing the
> paramspec.
>
>
> - --
> - - m&m
>
> Matt Miller < [email-masked]<mailto:[email-masked]> >
> Cisco Systems, Inc.
>
> On 5/9/14, 10:31 AM, Brian Campbell wrote:
>> So while OAEPWithSHA-256AndMGF1Padding is a little redundant with the
>> OAEPParameterSpec, I'd say NOPADDING seems a little contradictory.
>> But what do I know?
>>
>> I'm still not sure how to concisely explain it in the appendix.
>>
>>
>> On Fri, May 9, 2014 at 7:43 AM, Richer, Justin P.
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>> I've found that it seems to work if you use NOPADDING, too:
>>
>> AlgorithmParameters algp =
>> AlgorithmParametersHelper.getInstance("OAEP", provider);
>> AlgorithmParameterSpec paramSpec = new OAEPParameterSpec("SHA-256",
>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
>> algp.init(paramSpec); Cipher cipher =
>> CipherHelper.getInstance("RSA/ECB/NOPADDING", provider);
>> cipher.init(Cipher.DECRYPT_MODE, priv, algp);
>>
>>
>> (Note that all the AlgorithmParametersHelper does in our code is
>> install the right provider if given.)
>>
>> -- Justin
>>
>> On May 9, 2014, at 9:32 AM, Brian Campbell
>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>> wrote:
>>
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#se
>>> ction-4.3
>>>
>>>
> is pretty clear about which parameters and hash functions to use
>>> in which OAEP alg.
>>>
>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#ap
>>> pendix-A.2
>>>
>>>
> that you refer to Axel probably needs to be updated because just
>>> listing RSA/ECB/OAEPWithSHA-256AndMGF1Padding for RSA-OAPE-265 isn't
>>> completely correct (well, maybe it is correct but a bit more is also
>>> needed).
>>>
>>> In order to do RSA-OAPE-265 correctly using the JCA APIs, one gets a
>>> Cipher with RSA/ECB/OAEPWithSHA-256AndMGF1Padding and then also
>>> initialize it with an OAEPParameterSpec that indicates that
>>> SHA-256 is to be used for MGF1 too.That looks something like this
>>> (or this is how I did it anyway):
>>>
>>> Cipher cipher =
>>> Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
>>> OAEPParameterSpec oaepSpec = new OAEPParameterSpec("SHA-256",
>>> "MGF1", MGF1ParameterSpec.SHA256, PSource.PSpecified.DEFAULT);
>>> cipher.init(Cipher.WRAP_MODE, publicKey, oaepSpec);
>>>
>>> The "...WithSHA-256AndMGF1Padding" part seems somewhat redundant
>>> with what's specified in the OAEPParameterSpec but I've not been
>>> able to figure out any other way to make it work. I don't know
>>> exactly how to say that in the Key Management Algorithm Identifier
>>> Cross-Reference but that's apparently what needs to be done.
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 7, 2014 at 8:30 AM, <[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>
>>> Does "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" mean that SHA-256 must be
>>> used for padding too?____
>>>
>>> I did not read it so.____
>>>
>>> Did somebody manage to use JCA correctly with one algorithm
>>> specifier like RSA/ECB/OAEPWithSHA-1AndMGF1PaddingWithSHA-256?____
>>>
>>> __ __
>>>
>>> Axel____
>>>
>>>
>>> A.2.
>>> <http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.htm
>>> l#rfc.appendix.A.2>
>>>
>>>
> Key Management Algorithm Identifier Cross-Reference
>>> <http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms-26.htm
>>> l#EncAlgXref>____
>>>
>>>
>>>
> This section contains a table cross-referencing the JWE alg
>>> (algorithm) values defined in this specification with the equivalent
>>> identifiers used by other standards and software packages. ____
>>>
>>> *JWE**____*
>>>
>>>
>>>
>>> *XML ENC**____*
>>>
>>>
>>>
>>> *JCA**____*
>>>
>>>
>>>
>>> *OID**____*
>>>
>>> RSA1_5____
>>>
>>>
>>>
>>> http://www.w3.org/2001/04/xmlenc#rsa-1_5____
>>>
>>>
>>>
>>> RSA/ECB/PKCS1Padding____
>>>
>>>
>>>
>>> 1.2.840.113549.1.1.1____
>>>
>>> RSA-OAEP____
>>>
>>>
>>>
>>> http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p____
>>>
>>>
>>>
>>> RSA/ECB/OAEPWithSHA-1AndMGF1Padding____
>>>
>>>
>>>
>>> 1.2.840.113549.1.1.7____
>>>
>>> RSA-OAEP-256____
>>>
>>>
>>>
>>> http://www.w3.org/2009/xmlenc11#rsa-oaep____
>>>
>>>
>>>
>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding____
>>>
>>>
>>>
>>> 1.2.840.113549.1.1.7____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> -----Original Message----- From: Antonio Sanso
>>> [mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>] Sent:
>>> Wednesday, May 07, 2014 4:24 PM To: Richer, Justin P. Cc: Brian
>>> Campbell; Matt Miller; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>;
>>> Nennker, Axel Subject: ***CAUTION_Invalid_Signature*** Re:
>>> [jose] RSA-OAEP-256 Example
>>>
>>> __ __
>>>
>>> On 5/7/14, 2:21 AM,
>>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>%3cmailto:[email-masked]<mailto:[email-masked]>>>
>>>
>>>
> wrote:____
>>>
>>>> I think that the java implementations implemented the spec
>>> and ____
>>>
>>>> everything is ok from that POV.____
>>>
>>>> __ __
>>>
>>>> These implementations are not broken.____
>>>
>>> __ __
>>>
>>> The JOSE Java implementations did not implement the spec,
>>> though.____
>>>
>>> draft-ietf-jose-json-web-algorithms § 4.3 clearly states the hash
>>> and mask generation functions are to use the same algorithm --
>>> SHA-1 (and____
>>>
>>> MGF1 with SHA-1) in the case of "RSA-OAEP", and SHA-256 (and MGF1
>>> with____
>>>
>>> SHA-256) in the case of "RSA-OAEP-256".____
>>>
>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> One could argue that when we replace SHA-1 by SHA-256 in one
>>> place ____
>>>
>>>> then we might consider to replace it in the padding too.____
>>>
>>> __ __
>>>
>>> That is exactly what draft-ietf-jose-json-web-algorithms
>>> specified.____
>>>
>>> __ __
>>>
>>>> __ __
>>>
>>>> My feeling is that using sha-256 for the padding does not
>>> give us more ____
>>>
>>>> security. YMMW____
>>>
>>>> __ __
>>>
>>> __ __
>>>
>>> That is a separate debate, I think.  The prevailing opinion (at
>>> least around the IETF) is "don't mix the algorithms".____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> --____
>>>
>>> - m&m____
>>>
>>> __ __
>>>
>>> Matt Miller < [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>%3cmailto:[email-masked]<mailto:[email-masked]>>> > Cisco
>>> Systems, Inc.____
>>>
>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> *From:*jose ____
>>>
>>>> [mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>>> <mailto:[email-masked]<mailto:[email-masked]>%3cmailto:[email-masked]<mailto:[email-masked]>%3e>]
>>>
>>>
> *On ____
>>>
>>>> Behalf Of *Brian Campbell *Sent:* Wednesday, May 07, 2014
>>> 6:54 AM ____
>>>
>>>> *To:* Matt Miller____
>>>
>>>> *Cc:* Antonio Sanso; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>%3cmailto:[email-masked]<mailto:[email-masked]>>> *Subject:* ____
>>>
>>>> Re: [jose]____
>>>
>>>> RSA-OAEP-256 Example____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> Thanks Matt.____
>>>
>>>> __ __
>>>
>>>> That is why I was looking for someone to verify using a
>>> different ____
>>>
>>>> platform. Though I was hoping it'd just work.____
>>>
>>>> __ __
>>>
>>>> Matt, can you try decrypting this one by chance? Using the
>>> same key. I ____
>>>
>>>> was more explicit with the parameters and, I think, MGF1
>>> should be ____
>>>
>>>> using SHA-256 now too.____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>>
>>> eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.fL5IL5cM
>>> Cj____
>>>
>>>
>>>
>>
>>> jU9G9_ZjsD2XO0HIwTOwbVwulcZVw31_rx2qTcHzbYhIvrvbcVLTfJzn8xbQ3UEL442Z
>>> gZ____
>>>
>>>
>>>
>>
>>> 1PcFYKENYePXiEyvYxPN8dmvj_OfLSJDEqR6kvwOb6nghGtxfzdB_VRvFt2eehbCA3gW
>>> pi____
>>>
>>>
>>>
>>
>>> OYHHvSTFdBPGx2KZHQisLz3oZR8EWiZ1woEpHy8a7FoQ2zzuDlZEJQOUrh09b_EJxmcE
>>> 2j____
>>>
>>>
>>>
>>
>>> L6wmEtgabyxy3VgWg3GqSPUISlJZV9HThuVJezzktJdpntRDnAPUqjc8IwByGpMleIQc
>>> Pu____
>>>
>>>
>>>
>>
>>> BUseRRPr_OsroOJ6eTl5DuFCmBOKb-eNNw5v-GEcVYr1w7X9oXoA.0frdIwx8P8UAzh1
>>> s9____
>>>
>>>
>>>
>>
>>> _PgOA.RAzILH0xfs0yxzML1CzzGExCfE2_wzWKs0FVuXfM8R5H68yTqTbqIqRCp2feAH
>>> 5G____
>>>
>>>
>>>
>> Svluzmztk2_CkGNSjAyoaw.4nMUXOgmgWvM-08tIZ-h5w____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> On Tue, May 6, 2014 at 8:39 PM, Matt Miller ____
>>>
>>>> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>%3cmailto:[email-masked]<mailto:[email-masked]>>>____
>>>
>>>> <mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>%3cmailto:[email-masked]<mailto:[email-masked]>>>>>
>>> wrote:____
>>>
>>>> __ __
>>>
>>>> Short answer: You are all equally broken -- except from a
>>> certain ____
>>>
>>>> point of view d-:____
>>>
>>>> __ __
>>>
>>>> Long answer: The code I have is based on OpenSSL, which is
>>> hard-coded ____
>>>
>>>> to use SHA1 for the hash and mask generation (boo!), which
>>> means one ____
>>>
>>>> has to implement OAEP-SHA256 from scratch (hiss!!).____
>>>
>>>> __ __
>>>
>>>> When I implemented it per RFC 3447 and ____
>>>
>>>> draft-ietf-jose-json-web-algorithms-26#section-4.3, I could
>>> not ____
>>>
>>>> decrypt the provided results.  When I hard-coded MGF1 to use
>>> "SHA1", I ____
>>>
>>>> could decrypt provided results.  A search through
>>> BouncyCastle's code ____
>>>
>>>> shows that "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" uses a
>>> Hash ____
>>>
>>>> function of____
>>>
>>>> SHA-256 generate the lHash but its MGF1 uses a "SHA-1".
>>> Further ____
>>>
>>>> evidence is shown with how [FORGE] can be made to work with
>>> Java ____
>>>
>>>> (search their homepage for "Compatible with Java's ____
>>>
>>>> RSA/ECB/OAEPWithSHA-256AndMGF1Padding").____
>>>
>>>> __ __
>>>
>>>> Reconciling all of this with____
>>>
>>>> draft-ietf-jose-json-web-algorithms#appendix-A.2 does not
>>> look to be ____
>>>
>>>> very straight-forward.  It appears that the JCA identifier
>>> is meant to ____
>>>
>>>> be "MGF1 with SHA1"; that ought to be explicitly noted.____
>>>
>>>> The XMLENC reference is arguably incomplete, since ____
>>>
>>>> "http://www.w3.org/2009/xmlenc11#rsa-oaep" defaults to ____
>>>
>>>> "http://www.w3.org/2009/xmlenc11#mgf1sha1" (MGF1 with SHA1);
>>> this can ____
>>>
>>>> probably be addressed by explicitly stating the mask
>>> generation ____
>>>
>>>> function is "http://www.w3.org/2009/xmlenc11#mgf1sha256"____
>>>
>>>> (MGF1 with SHA-256).____
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>> __ __
>>>
>>>
>>>
>>>
>>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>>> Campbell Portfolio Architect @      [email-masked]<mailto:[email-masked]>
>>> <mailto:[email-masked]<mailto:[email-masked]>> phone   +1 720.317.2061<tel:%2B1%20720.317.2061>
>>> <tel:%2B1%20720.317.2061> Connect with us. twitter logo
>>> <https://twitter.com/pingidentity> youtube logo
>>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo
>>> <https://www.linkedin.com/company/21870> Facebook logo
>>> <https://www.facebook.com/pingidentitypage> Google+ logo
>>> <https://plus.google.com/u/0/114266977739397708540> slideshare logo
>>> <http://www.slideshare.net/PingIdentity> flipboard logo
>>> <http://flip.it/vjBF7> rss feed icon
>>> <https://www.pingidentity.com/blogs/>
>>>
>>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution
>>> | 19-23 July, 2014 | Monterey, CA
>>> <https://www.cloudidentitysummit.com/>
>>>
>>>
>>
>>
>>
>>
>> -- Ping Identity logo <https://www.pingidentity.com/> Brian
>> Campbell Portfolio Architect @       [email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>> phone    +1 720.317.2061<tel:%2B1%20720.317.2061> Connect
>> with us. twitter logo <https://twitter.com/pingidentity> youtube logo
>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo
>> <https://www.linkedin.com/company/21870> Facebook logo
>> <https://www.facebook.com/pingidentitypage> Google+ logo
>> <https://plus.google.com/u/0/114266977739397708540> slideshare logo
>> <http://www.slideshare.net/PingIdentity> flipboard logo
>> <http://flip.it/vjBF7> rss feed icon
>> <https://www.pingidentity.com/blogs/>
>>
>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution
>> | 19-23 July, 2014 | Monterey, CA
>> <https://www.cloudidentitysummit.com/>
>>
>>
>>
>>
>> _______________________________________________ jose mailing list
>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/jose
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTbQR6AAoJEDWi+S0W7cO14kgH/3RsEgO+jMpMOmHKLxB695iK
> DHO5wvJKXE/WI5WLlhEpK86TVcghdL7RJWxBXMw5Rz8+p27HLrr0mrBWw7PYBzCL
> 31fHFpd/OdsI8iaSnVeLXuG/fiPNBmPagYQ0iN/FMgVDI+Ra61dUT1Cq0yyFWFVj
> 1n1qzkjDhKhw9OkazcKWxp2fXvjhwaxtI/WrchBBPg5bJt0JA4MvlMhvoQHu5+gL
> d2Qox1TO0j3XltTkvtliorDku1aHCFfNaqLwvDxfu89H+ayvqMHTzgi274y9JmGi
> YvN1zzITnYkvpaeGC978sqLvg1j5Zh4VvO+3zquFeVJvu4801hrMyzzeSyeRpdc=
> =2XGV
> -----END PGP SIGNATURE-----

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

--
[Ping Identity logo]<https://www.pingidentity.com/>

Brian Campbell
Portfolio Architect
@

[email-masked]<mailto:[email-masked]>

[phone]

+1 720.317.2061

Connect with us…

[twitter logo]<https://twitter.com/pingidentity>[youtube logo]<https://www.youtube.com/user/PingIdentityTV>[LinkedIn logo]<https://www.linkedin.com/company/21870>[Facebook logo]<https://www.facebook.com/pingidentitypage>[Google+ logo]<https://plus.google.com/u/0/114266977739397708540>[slideshare logo]<http://www.slideshare.net/PingIdentity>[flipboard logo]<http://flip.it/vjBF7>[rss feed icon]<https://www.pingidentity.com/blogs/>

[Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>