This is indeed a JCA oddity, when "PKCS5Padding" is specified Java
actually does "PKCS7Padding".

If you stick "PKCS7Padding" you'll get an

|NoSuchAlgorithmException: Cannot find any provider supporting 
AES/CBC/PKCS7Padding


|

Vladimir

On 27.03.2015 08:20, Anders Rundgren wrote:
> On 2015-03-27 01:31, Brian Campbell wrote:
>> I am pretty sure you should not make that change to the JCA algorithm
>> string.
> >  I'll have to search around to remember why, some oddity of Java I
> think,
> > but I'm away from my laptop right now and that one is too much to
> research on a phone.
>
> Indeed, this is an old SUN bug that we have to put up with:
> http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html
>
> It is worth a note though.
>
> Anders
>
>>
>> On Mar 26, 2015 6:41 PM, "Mike Jones" <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     I am working on the formatting of the algorithm cross-reference
>> tables in JWA Appendix A
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#appendix-A
>> with the RFC Editor to make them more readable.  When looking at the
>> table content (in a more readable rendition I’ll share with you
>> soon), I noticed that this string appears for the JCA value of three
>> algorithms:____
>>
>>                     AES/CBC/PKCS5Padding____
>>
>>     which I believe should be____
>>
>>                     AES/CBC/PKCS7Padding____
>>
>>     __ __
>>
>>     This would be consistent with the changes made in -28 for the
>> reasons described in this thread. JAVA IMPLEMENTERS– If you are
>> currently using AES/CBC/PKCS5Padding can you please verify that your
>> implementation still works after changing this string to
>> AES/CBC/PKCS7Padding and that the results are still correct and reply
>> to us letting us know what happened? Matt, if your code for the
>> cookbook is in Java, it would be especially good if you made this
>> code change and verified that nothing changes in the output.____
>>
>>     __ __
>>
>>     Also, this clearly inconsistent sentence currently occurs in
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-40#section-5.2.1:____
>>
>>
>>            CBC-PKCS5-ENC(X, P) denotes the AES CBC encryption of P
>> using PKCS____
>>
>>            #7 padding using the cipher with the key X.____
>>
>>     __ __
>>
>>     I believe that the identifier CBC-PKCS5-ENCshould be changed to
>> CBC-PKCS7-ENC.____
>>
>>     __ __
>>
>>     Unless people disagree, I will plan to apply these corrections
>> during AUTH48.____
>>
>>     __ __
>>
>>                                                                 
>> Thanks all,____
>>
>>                                                                  --
>> Mike____
>>
>>     __ __
>>
>>     *From:*jose [mailto:[email protected]
>> <mailto:[email protected]>] *On Behalf Of *Mike Jones
>>     *Sent:* Friday, June 20, 2014 7:03 PM
>>     *To:* Shaun Cooley (shcooley)
>>     *Cc:* [email protected] <mailto:[email protected]>; Matt Miller (mamille2)
>>     *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27:
>> section-5.2 (PKCS #5)____
>>
>>     __ __
>>
>>     This change has been incorporated in the -28 drafts.____
>>
>>     __ __
>>
>>                                                                 
>> Thanks again, Shaun,____
>>
>>                                                                  --
>> Mike____
>>
>>     __ __
>>
>>     *From:*jose [mailto:[email protected]] *On Behalf Of *Mike Jones
>>     *Sent:* Friday, June 13, 2014 2:27 PM
>>     *To:* Shaun Cooley (shcooley)
>>     *Cc:* [email protected] <mailto:[email protected]>; Matt Miller (mamille2)
>>     *Subject:* Re: [jose] draft-ietf-jose-json-web-algorithms-27:
>> section-5.2 (PKCS #5)____
>>
>>     __ __
>>
>>     (Adding the JOSE working group)____
>>
>>     __ __
>>
>>     I believe you’re right.  I’ll plan to make this change in the
>> next version of the spec.____
>>
>>     __ __
>>
>>     Thanks for the careful read!____
>>
>>     __ __
>>
>>                                                                  --
>> Mike____
>>
>>     __ __
>>
>>     *From:*Shaun Cooley (shcooley) [mailto:[email protected]]
>>     *Sent:* Friday, June 13, 2014 10:34 AM
>>     *To:* Mike Jones
>>     *Cc:* Matt Miller (mamille2)
>>     *Subject:* draft-ietf-jose-json-web-algorithms-27: section-5.2
>> (PKCS #5)____
>>
>>     __ __
>>
>>     Michael –____
>>
>>       I am working on implementing a browser compatible JS
>> implementation of JOSE, based on the work Matt Miller did for
>> Node.JS.  While going through the spec, I noticed that PKCS #5 is
>> called out for the AES-CBC ciphers.  Shouldn’t this be PKCS #7?____
>>
>>     __ __
>>
>>     PKCS #5 – RFC2898 section 6.2 specifies:____
>>
>>     The padding string PS shall consist of 8 - (||M|| mod 8) octets
>> all having value 8 - (||M|| mod 8).____
>>
>>     __ __
>>
>>     PKCS #7 – RFC2315 section 10.3 note 2 specifies:____
>>
>>     For such algorithms, the method shall be to pad the input at the
>> trailing end with k - (l mod k) octets all having value k - (l mod
>> k), where l is the length of the input.____
>>
>>     __ __
>>
>>     PKCS #7 allows for padding in block sizes of 2-255 bytes, whereas
>> PKCS #5 is intended for block sizes of 8.  This means that PKCS #7 is
>> a superset of #5, and given that AES is a block size of 16, it seems
>> the spec should require PKCS #7.____
>>
>>     __ __
>>
>>     Thoughts?____
>>
>>     __ __
>>
>>     *Shaun Cooley*
>>     DISTINGUISHED ENGINEER.ENGINEERING
>>     Collaboration Technology Group
>>     [email protected] <mailto:[email protected]>
>>     Phone: *+1 408 902 3344 <tel:%2B1%20408%20902%203344>*
>>     Mobile: *+1 310 293 2087 <tel:%2B1%20310%20293%202087>*____
>>
>>        
>>
>>     http://www.cisco.com/web/europe/images/email/signature/logo05.jpg
>>     Cisco.com <http://www.cisco.com/>____
>>
>>     __ __
>>
>>     This email may contain confidential and privileged material for
>> the sole use of the intended recipient. Any review, use, distribution
>> or disclosure by others is strictly prohibited. If you are not the
>> intended recipient (or authorized to receive for the recipient),
>> please contact the sender by reply email and delete all copies of
>> this message.____
>>
>>     For corporate legal information go to:
>>    
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html____
>>
>>     __ __
>>
>>     __ __
>>
>>
>>     _______________________________________________
>>     jose mailing list
>>     [email protected] <mailto:[email protected]>
>>     https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose

-- 
Vladimir Dzhuvinov :: [email protected]

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to