I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan
------------------------------

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam
------------------------------


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

OK.  So, try decrypt-data  rather than  decrypt-key. 

------------------------------
Joseph Morgan
------------------------------


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam
------------------------------


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

------------------------------
Joseph Morgan
------------------------------


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

Thanks Joseph, Yes you are right, the client is sending the key (encrypted using the pub key) as part of the message and It is base64 encoded

This is what at high level client is doing :

generate symmetric key (buffer) -> encrypt using public key (buffer) -> convert buffer to base64 

------------------------------
Rajesh Rajaratnam
------------------------------


Original Message:
Sent: Mon August 28, 2023 09:49 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

------------------------------
Joseph Morgan


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

So, in my experience, when DataPower just fails decryption, it has something to do with what is being decrypted.  I doubt it is the base64 conversion, and from your description it doesn't seem to be an algorithm mismatch, but I'm wondering what DataPower "sees" after it is turned into binary after converting from base64.  Is the key the right length?  Is it padded correctly if padding is applied?  What encoding is applied before encryption or when converting to base64?

In your Java example, is "decrypt" being invoked after decoding the client generated message from base64?

------------------------------
Joseph Morgan
------------------------------


Original Message:
Sent: Mon August 28, 2023 10:09 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks Joseph, Yes you are right, the client is sending the key (encrypted using the pub key) as part of the message and It is base64 encoded

This is what at high level client is doing :

generate symmetric key (buffer) -> encrypt using public key (buffer) -> convert buffer to base64 

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 09:49 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

------------------------------
Joseph Morgan


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

So, in my experience, when DataPower just fails decryption, it has something to do with what is being decrypted.  I doubt it is the base64 conversion, and from your description it doesn't seem to be an algorithm mismatch, but I'm wondering what DataPower "sees" after it is turned into binary after converting from base64.  Is the key the right length?  Is it padded correctly if padding is applied?  What encoding is applied before encryption or when converting to base64?

In your Java example, is "decrypt" being invoked after decoding the client generated message from base64?

Thanks Joseph, Yes you are right, the client is sending the key (encrypted using the pub key) as part of the message and It is base64 encoded

This is what at high level client is doing :

generate symmetric key (buffer) -> encrypt using public key (buffer) -> convert buffer to base64 

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 09:49 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

------------------------------
Joseph Morgan


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

Hi @Joseph Morgan

We are still working on this and have noticed that decryption is failing in DataPower when the client is performing the RSA-OAEP encryption with SHA-256 OAEP digest and MGF algorithm

We are using dp:decrypt-key() with the RSA-OAEP key transport identifier and the algorithm for the mask generation function like this:
dp:decrypt-key(encryptedKey, recipient, http://www.w3.org/2009/xmlenc11#rsa-oaep, OAEPParameters, OAEPDigestAlgorithm, MGFAlgorithm)

Tested it further by encrypting the key (using Java code) and then decrypt the key in DataPower by providing various OAEPDigestAlgorithm and MGFAlgorithm combinations as below: (Note: Each time we have adjusted the encryption so that both encryption and decryption matches)

#1

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2001/04/xmlenc#sha256' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha1' This one worked in DataPower

#2

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2000/09/xmldsig#sha1' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha1' This one worked in DataPower

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2001/04/xmlenc#sha256' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha256' This one failed in DP

Even though both dp:decrypt-key() - IBM Documentation , dp:encrypt-key() - IBM Documentation lists the SHA-256 as a valid algorithm for both digest (http://www.w3.org/2001/04/xmlenc#sha256) and MGF(http://www.w3.org/2009/xmlenc11#mgf1sha256); this combination is not working in our tests

Regards

So, in my experience, when DataPower just fails decryption, it has something to do with what is being decrypted.  I doubt it is the base64 conversion, and from your description it doesn't seem to be an algorithm mismatch, but I'm wondering what DataPower "sees" after it is turned into binary after converting from base64.  Is the key the right length?  Is it padded correctly if padding is applied?  What encoding is applied before encryption or when converting to base64?

In your Java example, is "decrypt" being invoked after decoding the client generated message from base64?

Thanks Joseph, Yes you are right, the client is sending the key (encrypted using the pub key) as part of the message and It is base64 encoded

This is what at high level client is doing :

generate symmetric key (buffer) -> encrypt using public key (buffer) -> convert buffer to base64 

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 09:49 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

------------------------------
Joseph Morgan


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

Hello Rajesh,

I am getting "Unknown hashing mechanism: 'http://www.w3.org/20'" in response while using below XSLT in datapower, please guide how to resolve this issue.

Please find below XSLT.

<xsl:stylesheet 
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:dp="http://www.datapower.com/extensions"
    xmlns:dpconfig="http://www.datapower.com/param/config"
    xmlns:apim="http://www.ibm.com/apimanagement"
    xmlns:webapi="http://www.ibm.com/apimanagement"
    xmlns:func="http://exslt.org/functions"
    xmlns:wxsl="http://www.w3.org/1999/XSL/TransformAlias"
    xmlns:exsl="http://exslt.org/common"
    extension-element-prefixes="dp dpconfig exsl apim"
    exclude-result-prefixes="wxsl func dp">

<xsl:value-of select="dp:encrypt-key($GeneratedKey,$recipient,'http://www.w3.org/2009/xmlenc11#rsa-oaep','http://www.w3.org/2000/09/xmldsig#sha256','http://www.w3.org/2009/xmlenc11#mgf1sha256')"/>

Hi @Joseph Morgan

We are still working on this and have noticed that decryption is failing in DataPower when the client is performing the RSA-OAEP encryption with SHA-256 OAEP digest and MGF algorithm

We are using dp:decrypt-key() with the RSA-OAEP key transport identifier and the algorithm for the mask generation function like this:
dp:decrypt-key(encryptedKey, recipient, http://www.w3.org/2009/xmlenc11#rsa-oaep, OAEPParameters, OAEPDigestAlgorithm, MGFAlgorithm)

Tested it further by encrypting the key (using Java code) and then decrypt the key in DataPower by providing various OAEPDigestAlgorithm and MGFAlgorithm combinations as below: (Note: Each time we have adjusted the encryption so that both encryption and decryption matches)

#1

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2001/04/xmlenc#sha256' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha1' This one worked in DataPower

#2

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2000/09/xmldsig#sha1' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha1' This one worked in DataPower

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2001/04/xmlenc#sha256' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha256' This one failed in DP

Even though both dp:decrypt-key() - IBM Documentation , dp:encrypt-key() - IBM Documentation lists the SHA-256 as a valid algorithm for both digest (http://www.w3.org/2001/04/xmlenc#sha256) and MGF(http://www.w3.org/2009/xmlenc11#mgf1sha256); this combination is not working in our tests

Regards

So, in my experience, when DataPower just fails decryption, it has something to do with what is being decrypted.  I doubt it is the base64 conversion, and from your description it doesn't seem to be an algorithm mismatch, but I'm wondering what DataPower "sees" after it is turned into binary after converting from base64.  Is the key the right length?  Is it padded correctly if padding is applied?  What encoding is applied before encryption or when converting to base64?

In your Java example, is "decrypt" being invoked after decoding the client generated message from base64?

Thanks Joseph, Yes you are right, the client is sending the key (encrypted using the pub key) as part of the message and It is base64 encoded

This is what at high level client is doing :

generate symmetric key (buffer) -> encrypt using public key (buffer) -> convert buffer to base64 

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 09:49 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

------------------------------
Joseph Morgan


Original Message:
Sent: Mon August 28, 2023 03:58 PM
From: Rajesh Rajaratnam
Subject: Hybrid encryption decryption using AES and RSA key pairs

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

Hi @Joseph Morgan and @all

Since this is an encryption-related thread I am posting my issue.
the end user is using Java for encryption and signing.
consider shared key, TOKEN = asdftghg which is 8 bytes and when using aes algorithm it will expect 256bit key.

below Java code will resolve this issue. if possible try to guide me in writing the equivalent gatewayscript for this.

java code:

SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
PBEKeySpec spec = new PBEKeySpec(TOKEN.toCharArray(), saltBytes, 65536, 256);
SecretKey tmp = factory.generateSecret(spec);
SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

any response is highly appreciated.
Thanks in advance!!

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

How is the request coming into DataPower?  JSON over REST or XML over something?

Generally speaking, though, if you want to use GatewayScript, start with the "crypto" module.  I suspect you'll want to verify a signature  (crypto.createVerify() & verify.update()), and then decrypt (crypto.createDecipheriv(), decipher.update(..), & decipher.final()).

Hi @Joseph Morgan and @all

Since this is an encryption-related thread I am posting my issue.
the end user is using Java for encryption and signing.
consider shared key, TOKEN = asdftghg which is 8 bytes and when using aes algorithm it will expect 256bit key.

below Java code will resolve this issue. if possible try to guide me in writing the equivalent gatewayscript for this.

java code:

SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
PBEKeySpec spec = new PBEKeySpec(TOKEN.toCharArray(), saltBytes, 65536, 256);
SecretKey tmp = factory.generateSecret(spec);
SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

any response is highly appreciated.
Thanks in advance!!

OK. So I think I misunderstood the scenario.  If I understand correctly, you don't have a Secret Key Object, but instead, you have the client sending you the key, encrypted by their public key provided via the message request to DataPower? 

From what you have described, I'd be focused on the encoding of the key.  Your Java example uses a byte array for the decryption.  What does the key look like in the request?  Base64?

Thanks a lot Joseph for checking this.

Yes, We can not have a shared symmetric key with the client as the client doesn't have a secured way to store the keys and it is public facing application. Hence the client has been asked to generate random symmetric key for each request and pass it along with the encrypted data. For this transport we are RSA asymmetric key cryptography.

We could have rely on the secured connection (https) between client and DataPower for this exchange, however this message further flow to another ESB layer before ultimately submitted to an external provider through another DataPower domain. The channel between DP and ESB is not secured (http).

We were initially planning to use the RSA public and private key pair between the client and DataPower for the data encryption, however DP is restricting this usage (probably due to a good reason that RSA ideally used for key exchange and signing scenarios)

Regards

------------------------------
Rajesh Rajaratnam


Original Message:
Sent: Mon August 28, 2023 12:06 PM
From: Joseph Morgan
Subject: Hybrid encryption decryption using AES and RSA key pairs

I'd have to build out a similar scenario to test this, but, I don't think decrypt-key was meant for decrypting symmetric keys on the box.

So, the first question I have is:  Is it absolutely necessary to encrypt the symmetric key on the appliance?

------------------------------
Joseph Morgan

Hi, 

See you are using IDG.2018.4.1.8, a lot of fixed are added afterwards.

IDG.2018.4 is end-of-service since 30 Apr 2023 (https://www.ibm.com/support/pages/ibm-datapower-gateway-firmware-support-lifecycle).

Try to upgrade first to a supported version and  test it again. If still failing, best to create a case. 

------------------------------
Jeroen Willems
Integration Architect - Managing Partner
Integration Designers
------------------------------

Hi,

I am facing a similar issue where I am successfully able to decrypt the key and IV coming from the client. But unable to decrypt the data, it throws Null decryption Result. Any help would be appreciated.

APIC Version : 10.0.5.4-5472

Note : Final result of bytes client is encoding/decoding with Base64, to convert it to string.

Hi, 

See you are using IDG.2018.4.1.8, a lot of fixed are added afterwards.

IDG.2018.4 is end-of-service since 30 Apr 2023 (https://www.ibm.com/support/pages/ibm-datapower-gateway-firmware-support-lifecycle).

Try to upgrade first to a supported version and  test it again. If still failing, best to create a case. 

------------------------------
Jeroen Willems
Integration Architect - Managing Partner
Integration Designers

Hi Divya,

Some pointers, may be useful..

in our case we were not able to make it working by keeping both mgf and digest algorithms as SHA-256, as below;

#1

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2001/04/xmlenc#sha256' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha1' This one worked in DataPower

#2

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2000/09/xmldsig#sha1' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha1' This one worked in DataPower

Key transport algorithm = 'http://www.w3.org/2009/xmlenc11#rsa-oaep'
OAEPDigestAlgorithm='http://www.w3.org/2001/04/xmlenc#sha256' and MGFAlgorithm='http://www.w3.org/2009/xmlenc11#mgf1sha256' This one failed in DP

Also looking at the sample messages you have provided, i could see non-parsable xml characters and think it would worth carefully check the decoding and base-64 conversions

Regards

Hi,

I am facing a similar issue where I am successfully able to decrypt the key and IV coming from the client. But unable to decrypt the data, it throws Null decryption Result. Any help would be appreciated.

APIC Version : 10.0.5.4-5472

Note : Final result of bytes client is encoding/decoding with Base64, to convert it to string.

Hi, 

See you are using IDG.2018.4.1.8, a lot of fixed are added afterwards.

IDG.2018.4 is end-of-service since 30 Apr 2023 (https://www.ibm.com/support/pages/ibm-datapower-gateway-firmware-support-lifecycle).

Try to upgrade first to a supported version and  test it again. If still failing, best to create a case. 

------------------------------
Jeroen Willems
Integration Architect - Managing Partner
Integration Designers