Layer7 API Management

Hi Team,

We are using gateway 9.1.

In the gateway 9.1 when we are trying to encrypt a string using PGP public key then the encrypted values comes in string format as shown below

LS0tLS1CRUdJTiBQR1AgTUVTU0FHRS0tLS0tClZlcnNpb246IEJDUEcgdjEuNDYKCmhJd0RTOXpr NFl6Z2ZjOEJBLzBhUDBKUnM4WGNLdzhYd2t6ODVCajhqQ2VqWGxFS0UzZEQvQTRhT3Yzb0VUckYK SXYwb0dwSmZ0dWNWamVuNFp3RVZKNnZwTFdTeS9OYkwxOWNnY2NITS9xNGJuOW8vMXZzenNwamJF a3ZRdUxJaQovTUQvNEZpRkRZRjVjd3YrK01aMExta2RrUkpmcWhaOTdtL0JzczJUVE10MVhUSmpT MDhZQ1JqMzAva21ndEpMCkFlVDVHYkhEZFhBaUdRbDdQYmFLMkdPTXZLdFV6blpOL2h3ZzdHT0t3 cjZGSGNUNDhZSlI1VUhzUXVYdks5MjUKWnY3eHo1MHlUajEwOFU3T0tGbzhkN1poRUVOaGZUdGlG Y25nCj13bDVhCi0tLS0tRU5EIFBHUCBNRVNTQUdFLS0tLS0K

The Same PGP Encryption when we do online it gives us a different encrypted value in a PGP MESSAGE format

-----BEGIN PGP MESSAGE-----
Version: BCPG v1.58
LS0tLS1CRUdJTiBQR1AgTUVTU0FHRS0tLS0tClZlcnNpb246IEJDUEcgdjEuNDYKCmhJd0RTOXpr
NFl6Z2ZjOEJBLzBXc1NZK1c1TGo0N21jL0kvNGN0UmI0alBIZDRxbk1FSWRUZlBpUHNSZDhwL1IK
MDNndVlGcDdhbUhQUC9Eam4vSzdUL0Y1K05nUkFwSll0THFmblVkdUpYeHVLajRieVJQaDkrZWJX
TjB6ZzNCZApNU0VnUndkNlhmakhDeWRTSGNFNUh2RlhCMHpGcjFyU21COGc2L0s2VEQ4UlFZSnBs
N2RSMVh2dU9tTzJKTkpMCkFTRml2R3J1NmFtNEs2WXhDeGk0aWlyQWwvZjNlQWVoTE90ZEROcnBr
RkMwRmxvd25kekZxbGg5U25TK25uN0sKMVBJc2JqMER1ZWhzMGJLakZLdmsrRHcxcHA4ZlVkVzI2
MTdWCj1MbERkCi0tLS0tRU5EIFBHUCBNRVNTQUdFLS0tLS0K
-----BEGIN PGP MESSAGE-----


Please let me know why there is difference in the output and how we can suggest clients
to decrypt it when they get a response from CA API Gateway in string format.


Thanks

They looks the same, just without title

Hi Mark,

In the Online tool i just pasted the encrypted string which obtained from the gateway and add the message tag

-----BEGIN PGP MESSAGE-----
Version: BCPG v1.58
LS0tLS1CRUdJTiBQR1AgTUVTU0FHRS0tLS0tClZlcnNpb246IEJDUEcgdjEuNDYKCmhJd0RTOXpr
NFl6Z2ZjOEJBLzBhUDBKUnM4WGNLdzhYd2t6ODVCajhqQ2VqWGxFS0UzZEQvQTRhT3Yzb0VUckYK
SXYwb0dwSmZ0dWNWamVuNFp3RVZKNnZwTFdTeS9OYkwxOWNnY2NITS9xNGJuOW8vMXZzenNwamJF
a3ZRdUxJaQovTUQvNEZpRkRZRjVjd3YrK01aMExta2RrUkpmcWhaOTdtL0JzczJUVE10MVhUSmpT
MDhZQ1JqMzAva21ndEpMCkFlVDVHYkhEZFhBaUdRbDdQYmFLMkdPTXZLdFV6blpOL2h3ZzdHT0t3
cjZGSGNUNDhZSlI1VUhzUXVYdks5MjUKWnY3eHo1MHlUajEwOFU3T0tGbzhkN1poRUVOaGZUdGlG
Y25nCj13bDVhCi0tLS0tRU5EIFBHUCBNRVNTQUdFLS0tLS0K
-----BEGIN PGP MESSAGE-----

But it is giving error.
As we need to explain the client how this particular encryption is done at our end for them to decrypt
it.

According to the document it is using AES 256 BIT Encryption.


Thanks,

Hi Suraj,

Just following up on this.

It seems the encryption are the same, as Mark had suggested earlier, at least from what you've shown us so far. Is the issue just that the backend can't decrypt it? If so, what error does the backend provide you?

Since we are encrypting it successfully, we can't really speak to why the backend can't decrypt it (if that's what is happening), at least not without accompanying information such as error messages or additional insight into what the backend is and things like that which may help us out.

Hi Suraj 

1) The proper PGP format (generally) would be the : 

-----BEGIN PGP MESSAGE-----
Version: BCPG v1.58

LS0tLS1CRUdJTiBQR1AgTUVTU0FHRS0tLS0tClZlcnNpb246IEJDUEcgdjEuNDYKCmhJd0RTOXpr
NFl6Z2ZjOEJBLzBhUDBKUnM4WGNLdzhYd2t6ODVCajhqQ2VqWGxFS0UzZEQvQTRhT3Yzb0VUckYK 
...
Y25nCj13bDVhCi0tLS0tRU5EIFBHUCBNRVNTQUdFLS0tLS0K
-----BEGIN PGP MESSAGE-----

That is the PEM (Pivacy Enhanced Mail) wrapped format.  PEM is very commonly used for certs/data used in email :

https://support.quovadisglobal.com/kb/a37/what-is-pem-format.aspx 

For PEM the blocks are identified via the --- XXXX --- headers, the binary data is base64 encoding have column limit of 76 (or is it 78).  The ascii and line size limit was set so as not upset old email servers which had some limitations - it is still very commonly used. 

2) The output of the PGPEncrypt Assertion however is just raw base64 encoding of the encrypted data - you can see the binary data is the same just does not have the PEM wrapper.

3) Also I see the space at character 76 or so - I suspect then that there is a \n there, but the editor you've looked at it in requires \r\n so they all appear on the same line : 

LS0tLS1CRUdJTiBQR1AgTUVTU0FHRS0tLS0tClZlcnNpb246IEJDUEcgdjEuNDYKCmhJd0RTOXpr NFl6

4) Solution ?

For Solution in your case it is probably easiest if on the APIM Gateway you can add an set-context-variable that adds the PEM type header & footer to the returned data :

eg: 

pemEncodedResponse = 

type:string

-----BEGIN PGP MESSAGE-----
Version: BCPG v1.58

${rawbase64encodeddata}
-----BEGIN PGP MESSAGE-----

Something like that or similar should work (and I seem to remember doing that when I had a few cases with PGP encryption).

It is probably cleanest to add on the Gateway side, rather than the client side but would work on the client side as well.

You could also raise enhancement request to the PGP assertion to add it.

Hope that helps. 

Cheers - Mark

(Also for encrypt I am a bit surprised you get the same b64data, usually there is some salt thrown in to ensure even if you encrypt the same messsage twice it will give different output encrypted value)