CryptoAPI + Cache in Minutes

CryptoAPI + Cache in Minutes


Hi all,

We are using the CryptoAPI to encrypt and decrypt some app data, the EncryptAES256 and DecryptAES256 actions to be more correct.

The problem is that we are getting a flood of SLOWEXTENSION messages on our logs every time we do an encryption or a decryption. We are not worry about the encryption because it's something that don't happens with very often, but the decryption happens almost every time we load a screen.

What we did?

We add 60min cache to the action where we do the decryption for when we have the same input(the same cipher to be decrypted) the system don't have the need to use the DecryptAES256 action, the problem is when even the input is always the same it's still using the DecryptAES256 instead of the value in cache and continues creating the SLOWEXTENSION messages for DecryptAES256 action:

cryptoapi.DecryptAES256 took 307 ms

Any ideas to solve this flood of messages? It's a CryptoAPI problem? Are we using the Cache on the correct way?

P.S. Other solution could be increase the time to 300ms


Diogo Miguel 

Hello Diogo,

You are probably testing the application in a Personal environment, right?
In this case, the server side caching is disabled and a message appears when you publish your application.

On a very simple test with an enterprise server, the cache worked with the EncryptAES256 as it should, using your approach (that is correct).

Eduardo Jauch

Hi Eduardo,

Thank you for your reply.

No, I'm already testing this in an enterprise server.

Any other idea?


Diogo Miguel

Hello Diogo,

Being an Enterprise server, I'll assume that Server Side Caching is enabled (you can check in the Service Center).
If it is, from OutSystems documentation (version 9), there are 3 reasons to the caching to be ignored:

  • The elapsed time since the element content was last cached exceeds the element's  Cache in Minutes value: the cached content is no longer valid, it is evaluated again, and the resulting content is updated in the cache;
  • The element has input parameters and there's no cached content for their new values: the element is evaluated and the resulting content is stored in a new entry in the cache;
  • The cache is invalidated: if the element content is invalidated by this operation, it is evaluated again, and the resulting content is updated in the cache.

So, unless you are invalidating the cache for some reason, or are putting a value in the Cache In Minutes that is too small, I would say that the second point is most probable: the input parameters are not really being cached or are being updated slightly different, forcing the execution of the action again.

I would start the troubleshooting doing a simple experiment with an action without input parameters updating a session variable and returning it as output (something like session.counter = session.counter + 1).
If caching is working, you should see always the same value as output of the action while the cache time is in place. I did this here ant it works, the value returned changes only after the cache time ends.

If it works, you need to check your input parameters to see if they are really the same or are being changed at some point.

Other than that, the only other reason I see, is that the server has the cache disabled, but in this case you would see a message during publishing.


I've tried your solution but didn't work, so probably I have the server cache disabled, but the problem is that I don't have any message telling me that.

Where on Service Center can I check if the cache server is disabled.

By the way, I'm developing in version 10 with Java stack.


Diogo Miguel

Hi Diogo,

The time taken by the DecryptAES funcion is meant to be slow. It is a security property, but it doesn't actually come from the decryption. It comes from the derivation of the key based on the password.

You can read more about this in this discussion associated with the component.

TLDR: if you are worried about the performance of decryption you can use the K- versions of the functions and do the key derivation seperately (using DeriveKey function).

Also, Java doesn't support the platform's builtin caching. You SHOULD have a message in your publication log with that.

Hello Diogo,

To see if server side caching is enabled, go to the service center, Administration, Licensing. It's one of the last items of the list

But this is the moment where I go "aaaaahhhh..."

The cache capability in java stack is missing:

And I think it is still missing on version 10...

In this case, you will have to resort to other methods to do caching.

Ok, so a bad new for me :/

Thank you guys for your replies.


Diogo Miguel

Did you see Ricardo reply?

Isn't it a good way to solve your problem?


João Rosado

Hi João,

Didn't solved my problem because now I have the SLOWEXTENSION messages for the KDeriveKey action:

cryptoapi.KDeriveKey took 284 ms


Diogo Miguel

Doing DeriveKey > KEncrypt is the same as doing Encrypt.

However, if you do DeriveKey once and save the result (in a site property, perhaps?) and then reuse the result, you don't do the DeriveKey steps again, and the KEncrypt ones should always be pretty quick.

If you're always using the same password, there's really no use in always deriving the key, you can just save the key.

Hi Ricardo,

Sorry for the late reply.

Thank you for your reply. 

I already had think on that solution but I have to discuss it with the DevOps of my team due to security reasons.


Diogo Miguel