[CryptoAPI] AES256 methods will work on this scenario?

Forge Component
Published on 3 Mar by Ricardo Silva
22 votes
Published on 3 Mar by Ricardo Silva

Hi all,

I have this requirement below but I can't get the correct results (encrypted /decrypted values) with none of the methods provided by this extension, maybe I'm doing something wrong...:( can you confirm(from your experience) if is possible or not possible use one of the methods provided by this extension to achieve what's asked below.

The goal is to send some data encrypted so they can decrypt and vice-versa.

PS: I send them the C# code of all methods from this extension, I assume they used on of these but I will confirm.

Thank you in advance  for your help.



"Password encryption

We had a look at the encryptions you suggested and here is what I have from the dev team:

This seems to work OK:


 use strict;
 use warnings;
 use Crypt::CBC;

 my $key = 'little brown mouse';
 my $data = '{ firstfield => "abc", secondfield = > "def" } ';
 my $cipher = Crypt::CBC->new(
 -key => $key,
 -keylength => '256',
 -cipher => "Crypt::OpenSSL::AES"

 my $encrypted = $cipher->encrypt_hex($data);
 my $decrypted = $cipher->decrypt_hex($encrypted);

 print $encrypted, "\n";
 print $decrypted, "\n";

the output is:

$ perl aes_cbc.pl
 { firstfield => "abc", secondfield = > "def" }

So if you can turn the hex above (53616…) into { firstfield => "abc", secondfield = > "def" }

using “little brown mouse” as the key to AES, then we’re in business.

Or even turn { firstfield => "abc", secondfield = > "def" } into the same hex (53616…) using the key “little brown mouse" "


Does the backend have to be in Perl ? I have created a Python library with an implementation of this extension methods:


Do you need to integrate specifically with that code?

Hi Ricardo,

thank you for quick feedback on this.

Our end game here it's no find a solution where I can send them some encrypted data from OS and they can decrypt on their side and they can send encrypted data and I can decrypt using the same key/password of course. 

Like I said I tried to encrypt and decrypt the test values they sent with the methods available on this extension but I was not able to get the correct results (decrypt or encrypt and get the same results), do you think one of the parts needs to install customized methods so we can achieve this?

I will ask them if they can use another language instead of pearl.

Thank you!


Well, if what you are trying to do is to communicate an encrypted value between OutSystems and your application and you have no legacy to think of, I would recommend you indeed use CryptoAPI.

In the Documentation topic you have a description of the encryption scheme that CryptoAPI uses, and it should be easy enough to implement in any language.

I wholeheartedly recommend AGAINST using the scheme your development team is trying to use as it has several flaws. A quick search on google in order to understand what it is doing yielded a couple of results where its use is discouraged (e.g. here and here ).

Hi Ricardo,

thank you for your help and advises.

We tried now to use a different approach and use methods from your extension.

Below is the feedback I received from the other dev team but I tried to encrypt and decrypt using the public/private key they shared with me ( I removed from the post but I can send you by PM if you needed to test) but I getting always the error it's attached. Am I doing something wrong here or the encryption they are using still not compatible with the ones from your extension? They said they used the same methods I send the in C# but in perl.

Thank you for your help and sorry for the time you're spending on this.


"We had another go by changing direction and using the API that was supplied originally – it does support RSA, which might be a better avenue of attack. Here is what we have done and can try out:

Using the following public key:


Just removed for security reasons


and the same text as before:

"{ firstfield => "abc", secondfield = > "def” }”

the API call is MssRSAEncrypt.

To decrypt messages they need the Private key:


Just removed for security reasons


and use the MssRSADecrypt API call.

We’ve encrypted the text using the public key, which should be able to be decrypted with MssRSADecrypt (this is Base64 encoded):






using the following code:


use Crypt::OpenSSL::RSA;

use Crypt::OpenSSL::X509;

use MIME::Base64;

use strict;

my $public_key = '/home/mvine/perlsaml/certs/sisenc.crt';

my $string = '{ firstfield => "abc", secondfield = > "def" }';

print encryptPublic($public_key,$string);


sub encryptPublic {

my ($public_key,$string) = @_;

my $key_string;

open(PUB,$public_key) || die "$public_key: $!";

read(PUB,$key_string,-s PUB); # Suck in the whole file


my $cert = Crypt::OpenSSL::X509->new_from_string($key_string);

my $public =


return encode_base64($public->encrypt($string));



Well, the short answer is that you're getting that error because the private key you're providing is not in the expected format. If you're providing a key in base64 encoded pkcs1, which you seem you are, that is not the format CryptoAPI takes its key.

A CryptoAPI private key looks something like this, which is the format .NET exports its RSA keys:



You can probably build this from your private key in perl using the "get_key_parameters" method.

.NET does not seem to provide good support built-in support for handling pkcs1 keys, so ... yeah ...


Hi again Ricardo,

I passed to the third party dev team the inputs you pass me on the previous post and this was their answer/solution:


After a little research, it would appear that the XML format below is .NET specific and is unusable anywhere else.

 We did some further research and think that the attached pfx file can be imported into a Microsoft key store and exported in a suitable format from there."

Do you think from the .pfx file they sent me I can get the correct public/private RSA keys to use on CryptoAPI methods? If yes, how can get these values?

Sorry for all the questions but this is all new for me.

Thank you again for your help.


Not exactly unusable*, but I do get their point.

Yes, if you get a pfx file, it seems that you should be able to obtain the xml representation of the key. See this stack overflow post for an example.

In any case, you seem to be wanting to encrypt JSON data. With this method and a 2048 bit key, you'll only be able to encrypt about 200 bytes of data. Do you think this will be enough for all future use of this ... integration?

Can't you simply use the python code I have provided? Can't your dev team build the symmetric encryption schema in perl?

*after some googling, I was able to use it in Java which doesn't support this format natively

Hi Ricardo,

I was able to use a workaround and get the "compatible" RSA xml structure from the private key they provide me using this tool: https://superdry.apphb.com/tools/online-rsa-key-converter

After I get the RSA XML structure I was able to use it in the CryptoAPI "RSADecrypt" method. To get the RSA public key I used your method "GetRSAPublicKey" passing the RSA private key and I was able to get a proper RSA public key that I use on the "RSAEncrypt" method. Now I'm able to decrypt/encrypt the data that the third party dev team sent to me. I'm not sure if is the best way to do it...but at the moment seems to work.

Now you raised a good point, the size of the data to encrypt/decrypt...I think we are going to drop the all package JSON encryption and only encrypt the value of the inputs we are passing on REST API. On that case, because are small data I think will work ok, but you're are right in future this encryption method maybe it's not the best one to use.

Ricardo just one idea, will not be possible to implement the same logic that website is using to get the the XML RSA keys from a .pem or .pfx directly on the CryptoAPI extension without using a third party logic? That would be awesome :)

Thank you again for amazing help on this!



Yes, that would be awesome, but it's also dependent on adding an additional 3rd party library which I would prefer to avoid, if possible.

As for the adequacy of the encryption methods used, it will depend a bit on how much the systems communicate.

Note that asymmetric encryption is much more CPU intensive than symmetric encryption, so it may also become a liability if the systems are always communicating.

This can also be viewed as a potential venue for a DoS attack, if an attacker can get your system to attempt decryption of large quantities of data / requests without proper clearance.