Hello,
I wanted to ask you guys about Apigee decrypting a formparam/queryparam/header which has been encrypted using AES_256_GCM_384. The length of the value will be maximum 13 chars. The expected traffic load will be quite big, to say the least. The communication protocol used is HTTPS. We're using Apigee-On-Premises.
Is it feasible that such an operation could be done in Apigee? If so, how is it going to affect the length of the flow? And the load on the platform itself?
I and my colleague think that such an operation should not be done in Apigee, but somewhere else in the whole flow (in front of/next to Apigee layer?) by means of a dedicated nodejs/Java/whatever app/proxy/something else.
Has anyone encountered such a "specific" requirement? How did you proceed with that?
Solved! Go to Solution.
I'm not familiar with a cipher named "AES_256_GCM_384"
For AES, the term "AES_256_GCM" refers to AES encryption with a 256 bit key, using Galois Counter Mode. That is something you can do in Apigee Edge.
There's an additional "SHA-384" in there, and I'm not sure what you'd do with that.
It sounds to me that you may be referring to the back-half of a TLS cipher suite, and yes, you can configure Apigee to handle TLS ciphers. See here: https://docs.apigee.com/api-platform/fundamentals/virtual-host-property-reference
That deals with crypto on the transport layer. You don't configure the "Proxy" to do that, but rather the virtual host.
If you are talking about crypto at the Messaging or Application layer (in the HTTP message payload), then I think you should examine the AES crypto callout to see if it satisfies. It does AES with 256-bit keys in mode=GCM.
https://github.com/DinoChiesa/ApigeeEdge-CustomPolicy-AesCrypto
And then if you need a SHA-384 hash of something,
https://github.com/DinoChiesa/ApigeeEdge-Java-Compute-Hash
I don't know what you mean by describing the expected traffic load as "quite high". That is a relative term of course.
AES encryption does incur a CPU cost, but it's a very efficient crypto.