I already posted this as a bug, but if anyone has any other suggestions:
There seems to be an issue with SymmetricDecrypt not returning the full decrypted message.
Given the following values -- these are all hex values:
encrypted data: 158ABE1495B20262E8779930863C211BF6EF8170285BDBF7E5E7E435E08929CE
IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Key: abcdef0123456789abcdef0123456789
OperationModeCBC!
PKCSPadding!
SymmetricDecrypt returns: 3~7~618~2~Limit
For converting the above into blobs, I used the CoderObject to HEXDECODE the above "string" values... The encrypted data I already had as a blob; the hex data string is a hex representation of the data received so you can test the following:
However, if I go to http://symmetric-ciphers.online-domain-tools.com/ and plug in those values, the full message is actually:
33 7e 37 7e 36 31 38 7e 32 7e 4c 69 6d 69 74 20
20 20 20 20 20 20 20 20 31 34 39 2e 30 30 7e 00
3~7 ~618~2~Limit 149.00~
... So, for whatever reason, SymmetricDecrypt fails to return the second block.
You must always pad with at least 1 byte (*1) => your third-party provider is also doing it wrong.
If you can't ask them to fix their code, you could pad the cipher with a nonce and discard it after decryption.
BUT: This is bug abusing, as PowerBuilder should not accept missing padding bytes.
*1 https://www.ibm.com/docs/en/zos/2.4.0?topic=rules-pkcs-padding-method
Unfortunately, the third party is unwilling to change their system as other systems have been using their system for years, and I don't think they have programmers on staff that could change their system if they wanted to. So it's legacy, and I just have to deal with it. *Sigh*. But yes, I agree, they are doing it wrong.
Anyway, I got around the issue by changing to a homegrown .NET dll where I could set the decryption padding to none, and now it's working great.