Question AES CBC encryption

Hi everybody,

Win 7,8,10
OE11.7

I'm dealing with a Docuware-archive and I have to encrypt a string with following conditions:

o Block Size = 128 Bits
o Cipher size = CBC (Cipher Block Chaining)
o Initialization vector (IV) = 128 bits
o Key length = 256 bits
o NO salt
o PKCS7 Padding

so I came up with the following code:
/*--------------------------------------------------------------------------------------------*/
SECURITY-POLICY:SYMMETRIC-ENCRYPTION-ALGORITHM = 'AES_CBC_256'.
SECURITY-POLICY:ENCRYPTION-SALT = ?. /* '?' --> NO salt-value is used */
SECURITY-POLICY:SYMMETRIC-ENCRYPTION-KEY = rawAES-key. /* this is a 32byte RAW-variable */
SECURITY-POLICY:SYMMETRIC-ENCRYPTION-IV = rawIV. /* this is a 16byte RAW-variable */


apart from that I don't know where to specify "Blocksize=128" I guess this code should be ok, but I get an encrypted string that is not accepted by Docuware.

So I started to look for solutions online and found a post in Progress Comunity 3 years ago, where somebody asked almost the same question. There was only 1 answer by David Abdala, who stated. "I have no sample, but most probably C# is using Microsoft encription libraries, which use an "inverse" order than OpenSSL. I had a similar issue using Windows encryption libraries in one end, and OpenSSL at the other end. "

My question is: can somebody confirm this ?
Does anybody happen to have a solution using the Microsoft-libraries from within OpenEdge and would be willing to share it ?

TIA, Wolf
 
Hi
For pdf encryption in pdfInclude I'm using just:
mEncrypted = ENCRYPT(p_Original, rEncryptKey, rInitVector, "AES_CBC_256"). // or "AES_CBC_128" for 128 bits keys
with none of the "security-policy" settings above, and this works.
So somewhat this must conform to the standards...
How is your code actually encrypting the string?
++
 
Hi Jean-Christophe,

sorry for the late answer, was away for a week.

I tried the same encryption as you do. I'm quite sure that the encryption i'm doing is right, the problem is DocuWare: they seem to use the Microsoft-libraries for decryption and that's why my program fails. But this is just a guess and I don't know how to prove it, because I have no idea how to use the Microsoft-libraries from within OpenEdge.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I have no idea how to use the Microsoft-libraries from within OpenEdge.
This approach seems like avoiding the problem rather than solving it. You should be able to use ABL crypto functions to do this. The point of standards is that you should be able to use any implementation (library) and get the correct output (ciphertext), given the same inputs (e.g. plaintext, cipher/mode, key, IV).

Let's go back to your business requirements:
o Block Size = 128 Bits
o Cipher size = CBC (Cipher Block Chaining)
o Initialization vector (IV) = 128 bits
o Key length = 256 bits
o NO salt
o PKCS7 Padding

And your implementation thus far:
SECURITY-POLICY:SYMMETRIC-ENCRYPTION-ALGORITHM = 'AES_CBC_256'.
SECURITY-POLICY:ENCRYPTION-SALT = ?. /* '?' --> NO salt-value is used */
SECURITY-POLICY:SYMMETRIC-ENCRYPTION-KEY = rawAES-key. /* this is a 32byte RAW-variable */
SECURITY-POLICY:SYMMETRIC-ENCRYPTION-IV = rawIV. /* this is a 16byte RAW-variable */
Have you double-checked that your key and IV values are correct? Have you tested that you are implementing PKCS7 padding correctly?

If so, I'd suggest you find some test vectors online and run them through a new ABL program (not your existing code); see if you get the correct results. Try this:
Test vectors — Cryptography 2.9.dev1 documentation

Scroll down to the entry for AES; it links to a NIST page for cryptographic algorithm validation. It has a PDF document with test vectors in it. I'm sure a google search will turn up others as well, or even online AES testers.

Either something is wrong in your code or you've found an OE bug. Given how long AES support has been in the product, I'd guess it's not a bug. If you can get test vectors to work correctly in your code, then OE works and your code is wrong. If you can't, then open a case with Progress TS.
 
I did what Rob suggested and did a short test, using the (unchanged) SECURITY-POLICY-Setting as shown above, and using simple values für AES-key and vector. Then I did the same encryption online at Online Tool for AES Encryption and Decryption

The encrypted strings are equal !
Even better: i decrypted my encrypted string with the online-tool and it came up with the originat text-to-encrypt.

So - without doubt (and without considering the PKCS7-implementation) - my encryption should be correct..

...which brings me back to where I started: I guess the problem is with Docuware.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
"All OpenEdge uses of ECB & CBC modes enable 'padding' by default. Because AES is a block-cipher of 16-byte blocks, the padding algorithm is PKCS#7. "
Ok, good; I didn't know that. I assumed you'd have to implement it yourself and modify the plaintext. Given what you've posted, you don't need to.
 
Got a C#-example that works, according to a Docuware-guy, but i'm not really able to translate it to ABL. If somebody could help out, I would be really thankful.
 

Attachments

  • Worker.cs.txt
    4.4 KB · Views: 7
  • Program.cs.txt
    902 bytes · Views: 9
forgot to mention: i'm aware of the funny thing they do in (worker.cs) "UrlTokenEncode": They are modifying the base64-encoded strings by replacing "+" and "/".
I implemented the same in my ABL-code, with no success.
 
Top