Sumu-Ning/AES

Bug in decryption algorithm?

Closed this issue · 10 comments

haimat commented

Hi, I have a string encrypted via OpenSSL command line:

echo "0075266945" | openssl enc -aes-256-cbc -a -nosalt -pass pass:TUA_DKK_CCIP_PW
H6xgbzDoj091wZjAj+mvKA==

This encrypted string "H6xgbzDoj091wZjAj+mvKA==" is stored in an ABAP string variable. According to a previous ticket here on GitHub I do the following: First call function SCMS_BASE64_DECODE_STR like so:

"Convert payload from Base64 to Hex
CALL FUNCTION 'SCMS_BASE64_DECODE_STR'
  EXPORTING
    input    = i_encrypted_data
    unescape = 'X'
  IMPORTING
    output   = lv_x_data.

Then I decrypt the string via your tool:

"Then decrypt the payload using the encryption key and init. vector, all in xstring format
CALL METHOD lr_aes_util->decrypt_xstring(
  EXPORTING
    i_data                  = lv_x_data
    i_key                   = lv_x_key   "CAE47A6067F0F2DCC728AF877530529038035761C89E0636DB043A6FE6815F04
    i_initialization_vector = lv_x_iv    "4BBF93F6535EC0AD41CBDEB346719675
    i_encryption_mode       = i_encryption_mode
  IMPORTING
    e_data                  = lv_x_result ).

Then I remove the trailing CR/LF bytes:

  DO.
    lv_len = xstrlen( lv_x_result ) - 1.
    IF lv_len = -1.
      EXIT.
    ENDIF.
    IF lv_x_result+lv_len(1) <= lc_byte_ws.
      "remove trailing non-printable character
      lv_x_result = lv_x_result(lv_len).
    ELSE.
      EXIT.
    ENDIF.
  ENDDO.

And the last steps:

"Finally convert the decrypted binary xstring back to a string again
CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
  EXPORTING
    buffer        = lv_x_result
  IMPORTING
    output_length = lv_len
  TABLES
    binary_tab    = lt_data.

CALL FUNCTION 'SCMS_BINARY_TO_STRING'
  EXPORTING
    input_length = lv_len
  IMPORTING
    text_buffer  = lv_result
  TABLES
    binary_tab   = lt_data.

MOVE lv_result TO r_decrypted_data.

However, now in r_decrypted_data the wrong data is stored: MF¬ö�í«a6Š©w
Is this a bug in your library, or am I doing something wrong here?

larshp commented

hi, can you help adding a full reproduceable example, eg a report or a class, perhaps add it on http://gist.github.com or in a public repository?

haimat commented

Sure, here is the class I have created from your AES library, as well as a sample report that calls this class.

https://gist.github.com/haimat/cd1465f09b65aab731279253340d6f1d

Sumu-Ning commented

I don't have the environment any more, but I suggest checking the encoding and possibly padding?

haimat commented

I tried to find an enconding problem, but didn't work out.
But I am far from being a crypto expert :(

Anything I could do for you guys to check that out with the working example I have posted?

raviandela commented

Hi, the gist you posted do not contain code for zdkk_rijndael_utility. Can you post that as well for checking the issue?

One more question, are you trying to recreate the utility classes yourself rather than importing from GIT?

haimat commented

Ohh yes, sure, sorry for that.
I have updated the Gist and added the code for the ZDKK_RIJNDAEL_UTILITY class.

Sumu-Ning commented
haimat commented

The method lr_aes_util->decrypt_xstring returns the following xstring in lv_x_result:
ACF617EDAB61368AA977014DB821C59E

raviandela commented

Hi the issue is the parameter p_encdat is converting all the data to upper case causing the issue.

I corrected the same and posted in this gist
https://gist.github.com/raviandela/6f4b1c85eb493f0274f7462e8ef1e984

Output I got is : "0075266945"

Attached is the output.

aes issue

haimat commented

Thank you very much, that's it!