Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (3)

Resolved SymmetricDecrypt not returning all data blocks

  1. Issue
0
Votes
Undo
  1. Richard Donagrandi
    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.

  1. Encryption
PFC Multi-table update
SMTP Client in PB 2022 R3 we are getting the error...
Responses (3)
Peter Pang @Appeon
Peter Pang @Appeon Accepted Answer Pending Moderation
  1. Thursday, 7 March 2024 07:11 AM UTC
  2. PowerBuilder
  3. # 1

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
Richard Donagrandi
  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.
Simon Jutzi
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
Richard Donagrandi
  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
Simon Jutzi
  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
Richard Donagrandi
  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.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Tuesday, 5 March 2024 23:08 PM UTC
  2. PowerBuilder
  3. # 3

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
Load more comments
Richard Donagrandi
  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
René Ullrich
  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
Richard Donagrandi
  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.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.