Manish Sahni wrote: I have developed an application and using the following keys for digital signatures those of which were placed in a file path (Directory) in testing environment.
1) XXX.p12 file - for Digital signature.
2) XXX.p12 file - for decryption of XML response.
3) XXX.cer file - for encrypting the session keys , input XML etc.
Since the files are on a particular file path location , the code is running fine.So for in the pre-production environment we have procured the CryptoGraphic Token from a CA and imported the XXX.p12 file for testing of the same, i am successfully able to digitally sign the request , However in case of decrypting the session key that is encrypted by the server using "RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING" i am getting the error as :-
My Testing Method is :-
I have found the issue is that the implementation of SunJCE's Cipher "RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING" is not compatible with other implementations (BouncyCastle/IAIK/PKCS11)
When setting AlgorithmParameters (with OAEPParameterSpec) an exception is thrown (javax.crypto.BadPaddingException)
Refer : Problems with Cipher "RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING" Bug Details: https://bugs.openjdk.java.net/browse/JDK-7038158?page=com.atlassian.jira.plugin.system.issuetabpanels%3aworklog-tabpanel
Is their any way that i can decrypt the data for RSA-OAEP padding.
Richard Tookey wrote:Once again I don't understand! You encrypt using "OAEPWITHSHA-256ANDMGF1PADDING" and then decrypt using "PKCS1Padding" and wonder why you get a javax.crypto.BadPaddingException ! Also, you say the problem is due to SunJCE's Cipher "RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING" but you are using bcProvider which presumably means BouncyCastle!
These inconsistencies make it difficult for anyone to take your problem seriously!
P.S. Did you look at the end of the bug report for a suggested way round the SunJCE provider bug?
Richard Tookey wrote:The BUG report you cited refers to the SunJCE provider and not the SunPKCS11 provider but since it is possible that the padding code it common to both then the BUG may be applicable. If you read to the end of the BUG report then you will see that a suggested work around for dealing with the BUG is to decrypt with no padding and write code to remove the MGF1 padding. The specification for MGF1 padding is available in rfc2437 which Google will find. As an alternative to coding MGF1 from scratch you could look at the Bouncy Castle source and extract the bits you need.
Don't get me started about those stupid light bulbs. |