1. Richard Donagrandi
  2. PowerBuilder
  3. Tuesday, 5 March 2024 22:28 PM UTC

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.

John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2024 23:08 PM UTC
  2. PowerBuilder
  3. # 1

Interesting (and frustrating, I'm sure)...

What version/release/build of PB are you using, Richard?

Do you have a code snippet for the example you've posted? I can maybe try it on some other versions.

Comment
  1. Richard Donagrandi
  2. Wednesday, 6 March 2024 03:52 AM UTC
//Given the above example, here's sample/test code:



blob lblb_key, lblb_iv, lblb_data, lblb_test

string ls_return



CoderObject lnv_CoderObject

lnv_CoderObject = Create CoderObject



CrypterObject lnv_CrypterObject

lnv_CrypterObject = Create CrypterObject



lblb_key = lnv_CoderObject.HexDecode('abcdef0123456789abcdef0123456789')

lblb_iv = lnv_CoderObject.HexDecode('00000000000000000000000000000000')

lblb_data = lnv_CoderObject.HexDecode('158ABE1495B20262E8779930863C211BF6EF8170285BDBF7E5E7E435E08929CE')



lblb_test = lnv_CrypterObject.SymmetricDecrypt(AES!, lblb_data, lblb_key, OperationModeCBC!, lblb_iv, PKCSPadding!)

ls_return = string(lblb_test, EncodingANSI!)



Return ls_return
  1. Helpful
  1. René Ullrich
  2. Wednesday, 6 March 2024 07:00 AM UTC
If I run your code I only get some cryptic return (NNNN|Y]YD).



So I think it is something wrong with your code or your data.

If I encrypt

337e377e3631387e327e4c696d69742020202020202020203134392e30307e00

with your key and iv I get

0F4D51509E1145303F2163C2B312F904E7A85DEA14810E9EBF7513ACD5E888E04576A65963CDD30BFB22C4FAF2812582

This I can successfully decrypt.



  1. Helpful
  1. Richard Donagrandi
  2. Wednesday, 6 March 2024 15:11 PM UTC
I may have put too many zeros in the IV. The IV should be zero, or HexDecode 32 zeros. Or Blob('0000000000000000'), or fill a byte[] with 16 0's.
  1. Helpful
There are no comments made yet.
Simon Jutzi Accepted Answer Pending Moderation
  1. Wednesday, 6 March 2024 08:12 AM UTC
  2. PowerBuilder
  3. # 2

Hi Richard

Your encrypted block isn't padded, that's why you get the wrong plaintext.

Btw: Usually, you shouldn't use a 0-IV, I hope that's just because it's an example.
@Appeon: You shouldn't silently ignore such errors.

Regards, Simon

Comment
  1. Richard Donagrandi
  2. Wednesday, 6 March 2024 14:58 PM UTC
Interesting thought, although the block size is 16, and the message shouldn't need padding. I did notice the SymmetricEncrypt will add an extra block of padding even though the message we're sending already fits within the 16-byte blocks without extra padding .. Either way, this is coming from a third-party I have to interact with and I'm unable to change how they're sending their messages. Also, the SymmetricDecrypt function does not allow setting CBC mode with no-padding.. Thanks for the insight!
  1. Helpful
  1. Simon Jutzi
  2. Wednesday, 6 March 2024 15:15 PM UTC
Hi Richard

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
  1. Helpful
  1. Richard Donagrandi
  2. Wednesday, 6 March 2024 18:49 PM UTC
Thanks, Simon.

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.
  1. Helpful 1
There are no comments made yet.
Peter Pang @Appeon Accepted Answer Pending Moderation
  1. Thursday, 7 March 2024 07:11 AM UTC
  2. PowerBuilder
  3. # 3

Hi Richard,

 

PB uses the third-party library cryptopp 8.7.0 (https://www.cryptopp.com/) to implement encryption and decryption. It's possible that the differences in internal algorithms between the two libraries are causing the issue. I suggest continuing with the .NET Dll solution.

 

Through reverse encryption, PB's SymmetricEncrypt generates longer encrypted data compared to what you provided, but it can be decrypted normally.

Encrypted data: 158ABE1495B20262E8779930863C211BF6EF8170285BDBF7E5E7E435E08929CEDE3127998AE92D36B6C15244394A893E

 

By the way, which bug did you submit? I couldn't find it.

 

Best Regards,

Peter

Comment
  1. Richard Donagrandi
  2. Thursday, 7 March 2024 16:13 PM UTC
I submitted the bug as private at https://www.appeon.com/standardsupport/newbug. It had a issue number, but I didn't write it down and I didn't get an email confirmation or anything. So I'm not sure what happened to it.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.