-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvement: EC (Elliptic-curve) Private Key Decryption Compatibility for Incoming Messages #403
Improvement: EC (Elliptic-curve) Private Key Decryption Compatibility for Incoming Messages #403
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution. Looks good to me.
In order to ensure the EC based certificate path gets tested as part of the CI/CD run please can you change the certificates for the "openas2b" alias to an EC algorithm certificate in the as2_certs.p12 file here:
https://github.com/OpenAS2/OpenAs2App/blob/master/Server/src/test/resources/OpenAS2ServerTest/OpenAS2A/config/as2_certs.p12
... then copy that file to the matching folder here overwriting the file of the same name in the below folder:
https://github.com/OpenAS2/OpenAs2App/blob/master/Server/src/test/resources/OpenAS2ServerTest/OpenAS2B/config/as2_certs.p12
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 Thank you!
I can only imagine that the Windows failures are a result of some change or error in configuring Windows instances deployed for running Java testing. |
Hi! I realized this needs more testing and also i am updating the encryption part as well to support EC based private keys. Currently the test between A and B partner is failing, i will commit my changes when i got over this problem and tested it throughly. |
Should i extend the getOutputEncryptor function to handle OID-s for EC as well? What i mean is rather than hardcoding the encryption algorithm here:
I will leave the keyAgreementOID as it is: CMSAlgorithm.ECMQV_SHA256KDF. But the encryptionOID should come from the partnership, in this context i am talking about: What are your thoughts? |
It is looking good. Yes please use the "algorithm" parameter passed into the encrypt() method for the EC by doing this on line 316:
|
…pientInfoGenerator and its OutputEncryptor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 Perfect. thank you for the excellent contribution.
Description
This pull request enhances OpenAS2’s BCCryptoHelper.java to support decryption for messages when the recipient’s private key is based on Elliptic Curve (EC) cryptography, in addition to the existing support for RSA. Previously, OpenAS2’s decryption functionality could only handle RSA-based private keys, leading to limitations when users relied on EC-based cryptography for incoming message decryption.
Problem Statement
In OpenAS2, incoming messages are encrypted by the sender using the recipient’s public certificate, and the recipient decrypts them using their private key. However, if the recipient’s private key was based on EC cryptography, OpenAS2’s BCCryptoHelper could not properly identify or process the decryption. This limitation prevented any message encrypted with the recipient’s EC-based public key from being decrypted by OpenAS2, thus obstructing the ability to receive encrypted messages for organizations using EC private keys.
Solution
The updated BCCryptoHelper.java extends the existing decryption method to support both RSA and EC-based private keys:
Changes Made
Benefits
Testing
This update has been successfully tested with both RSA- and EC-based cryptography setups to confirm that OpenAS2 can now decrypt incoming messages regardless of the recipient’s key type.
Summary
The enhancement broadens OpenAS2’s decryption capability, enabling it to support both RSA and EC-based private keys, which aligns with modern cryptographic standards and allows users greater flexibility in their security configurations. This approach resolves the previous limitations with EC cryptography, ensuring that OpenAS2 remains compatible with a wider range of encryption standards in secure communications.