bc-java
bc-java copied to clipboard
bcgit
Add id_RSAES_OAEP to asymmetricWrapperAlgNames
This makes it easier to decode SCEP requests from some Windows computers with OAEP Padding using the JSCEP library. Without the patch, I see this Exception:
Caused by: org.bouncycastle.cms.CMSException: exception unwrapping key: cannot create cipher: Cannot find any provider supporting 1.2.840.113549.1.1.7 at org.bouncycastle.cms.jcajce.JceKeyTransRecipient.extractSecretKey(Unknown Source) at org.bouncycastle.cms.jcajce.JceKeyTransEnvelopedRecipient.getRecipientOperator(Unknown Source) at org.jscep.message.PkcsPkiEnvelopeDecoder$InternalKeyTransEnvelopedRecipient.getRecipientOperator(PkcsPkiEnvelopeDecoder.java:150) at org.bouncycastle.cms.KeyTransRecipientInformation.getRecipientOperator(Unknown Source) at org.bouncycastle.cms.RecipientInformation.getContentStream(Unknown Source) at org.bouncycastle.cms.RecipientInformation.getContent(Unknown Source) at org.jscep.message.PkcsPkiEnvelopeDecoder.decode(PkcsPkiEnvelopeDecoder.java:92) ... 67 more Caused by: org.bouncycastle.operator.OperatorCreationException: cannot create cipher: Cannot find any provider supporting 1.2.840.113549.1.1.7 at org.bouncycastle.operator.jcajce.OperatorHelper.createAsymmetricWrapper(Unknown Source) at org.bouncycastle.operator.jcajce.JceAsymmetricKeyUnwrapper.generateUnwrappedKey(Unknown Source) ... 74 more Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting 1.2.840.113549.1.1.7 at javax.crypto.Cipher.getInstance(Unknown Source) at org.bouncycastle.jcajce.util.DefaultJcaJceHelper.createCipher(Unknown Source) ... 76 more
Unfortunately this patch would almost completely break the use of OAEP in the CMS library (evidently it would work for the case specified). I think there's a way out of this though. If I understand correctly the system only recognizes the full name. Can you tell me what other OAEP algorithms the system can handle, or is it just one.
I do not know which ciphers Windows are using, or even under which conditions Windows sends SCEP requests using OAEP instead of the more common PKCS1 padding. I only know that sometimes Windows will use the OID 1.2.840.113549.1.1.7 for the algorithm used for the envelope key, and testing showed that the key can then be decoded using RSA/ECB/OAEPWithSHA-1AndMGF1Padding. It is possible that Windows could use the same OID for other algorithms as well, but that would make it really hard to decode their SCEP requests.
On Tue, May 18, 2021 at 3:26 PM dghgit @.***> wrote:
Unfortunately this patch would almost completely break the use of OAEP in the CMS library (evidently it would work for the case specified). I think there's a way out of this though. If I understand correctly the system only recognizes the full name. Can you tell me what other OAEP algorithms the system can handle, or is it just one.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bcgit/bc-java/pull/953#issuecomment-842926019, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARCX7JVBRM4QQI7KXR2OMTTOIJCBANCNFSM447W5IOA .
OAEP also has an algorithm parameters block in the AlgorithmIdentifier - RSA/ECB/OAEPWithSHA-1AndMGF1Padding is what you would call the default setting. The question was more about what does the provider being used had available in it? Or are you saying you are using the BC provider?
https://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html
The above link lists all the possible ciphers that every java platform must implement. We are interested in these 3: RSA/ECB/PKCS1Padding (1024, 2048) RSA/ECB/OAEPWithSHA-1AndMGF1Padding (1024, 2048) - OID mapping missing in BC based on the current PR RSA/ECB/OAEPWithSHA-256AndMGF1Padding (1024, 2048) - OID mapping missing in BC based on the current PR
As Piyush mentioned, all Java implementations since Java 7 are required to support RSA/ECB/OAEPWithSHA-1AndMGF1Padding. If an older Java implementation is used, the algorithm may not be found, but at least the exception will be better than "Cannot find any provider supporting 1.2.840.113549.1.1.7". It is also possible to override/supplement the mapping in asymmetricWrapperAlgNames by using the extraAlgNames parameter in createAsymmetricWrapper, but the structure of the JSCEP library we are using makes it hard for us to do that.
On Tue, May 18, 2021 at 5:11 PM dghgit @.***> wrote:
OAEP also has an algorithm parameters block in the AlgorithmIdentifier - RSA/ECB/OAEPWithSHA-1AndMGF1Padding is what you would call the default setting. The question was more about what was the provider being used had available in it? Or are you saying you are using the BC provider?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I'll look into it - it'll need to map to the algorithm name based on the parameters though the OID is for OAEP, not for OAEP with SHA1 or SHA256, so what's required is to recognise the oid explicitly and then generate an algorithm name from the combination of the OID and the parameters block.
@dghgit @cubicrace @jensthomassen
I also need this for my project. My Java application throws similar exception when unwrapping PKCS7 CMS envelope created by ASP.NET.
I don't have the answer for the algorithm naming yet. But I find this OID to name mapping in AllTests.java.
assertEquals(nameFinder.getAlgorithmName(PKCSObjectIdentifiers.id_RSAES_OAEP), "RSAOAEP");
So we might need this mapping in PR
asymmetricWrapperAlgNames.put(PKCSObjectIdentifiers.id_RSAES_OAEP, "RSAOAEP");
instead of
asymmetricWrapperAlgNames.put(PKCSObjectIdentifiers.id_RSAES_OAEP, "RSA/ECB/OAEPWithSHA-1AndMGF1Padding");
Any thought on that?
ASP.NET PKCS7 CMS code link for reference: https://referencesource.microsoft.com/#System.Security/system/security/cryptography/pkcs/envelopedpkcs7.cs
I have tested and can confirm "RSA/ECB/OAEPWithSHA-1AndMGF1Padding" is the right name. I'm able to unwrap PKCS7 CMS envelope created using ASP .NET.