cancel
Showing results for 
Search instead for 
Did you mean: 

MD5 functionality?

Former Member

Accepted Solutions (0)

Answers (2)

Answers (2)

rainer_liebisch
Contributor
0 Kudos

Hi Eddie,

Brian is right. If you call function group "SECH", you will find some function modules for encryption. Have a look at the description behind the object name. Some of them are marked as obsolete or "Do not use".

Regards,

Rainer

eddy_declercq
Active Contributor
0 Kudos

It seems to be that the new function is giving back a 160 bit hash back instead of the usual 32 bytes, which is used in other languages.

The old version is capable of hashing tables but no strings. The thing is that I have a table [218x255] which needs to be hashed.

I can convert it to a string for the new function, but I get of course a different hash back.

former_member185932
Participant
0 Kudos

Using the function MD5_CALCULATE_HASH_FOR_CHAR with text 'CMEHIL' I get two different hashes depending on whether I use a table or the DATA parameter:

With 'CMEHIL' passed as the EXPORTING DATA parameter it gives 19C036EDEBD14B355AF79F87ABAAD276

Passing 'CMEHIL' in as a single line in a table to the same function gives 326555E6A161BA0116BCF2AF94CE5F5C

Any idea why the TABLE version gives a different hash from what is essentially the same data?

Cheers,

JB

eddy_declercq
Active Contributor
0 Kudos

Hi,

That's caused by the fact that you're calling the FM with SE37. It checks if the table is provided (which is always the case in SE37) and converts that one. It'll be a hash for the "empty" table.

You need to call the FM within a report, then the hash will be the same.

Eddy

former_member185932
Participant
0 Kudos

Eddy,

Thanks for your reply. I was testing the MD5 function module in a report rather that using the SE37 testing tool. Here is the code that gives the results I described:

types: begin of t_hash_data,
         line type text4096,
       end of t_hash_data.

data: w_hash like MD5_FIELDS-HASH,
      w_hash2 type HASH160,
      wa_hash_data type t_hash_data,
      i_hash_data type standard table of t_hash_data.

wa_hash_data-line = 'CMEHIL'.
append wa_hash_data to i_hash_data.

CALL FUNCTION 'MD5_CALCULATE_HASH_FOR_CHAR'
  IMPORTING
    HASH                 = w_hash
  TABLES
    DATA_TAB             = i_hash_data
  EXCEPTIONS
    NO_DATA              = 1
    INTERNAL_ERROR       = 2
    OTHERS               = 3.
IF SY-SUBRC eq 0.
  write:/ 'MD5 hash using Table:', w_hash.
ENDIF.

CALL FUNCTION 'MD5_CALCULATE_HASH_FOR_CHAR'
  EXPORTING
    DATA                 = 'CMEHIL'
*   LENGTH               = 0
*   VERSION              = 1
  IMPORTING
    HASH                 = w_hash
  EXCEPTIONS
    NO_DATA              = 1
    INTERNAL_ERROR       = 2
    OTHERS               = 3.
IF SY-SUBRC eq 0.
  write:/ 'MD5 hash using Data :', w_hash.
ENDIF.

Can you see any problems with this code or anything that I am doing wrong to get two different hash values?

Thanks,

JB

former_member185932
Participant
0 Kudos

With additional testing i have found that the hash for the table changes dependent upon the definition for the LINE field in my TYPES definition. For example, in the code I provided the hash for 'CMEHIL' is 326555E6A161BA0116BCF2AF94CE5F5C. Change the LINE definition to be type TEXT100 and the hash is then 37A3CE21ECEC8398CDAE5BA63DF7393B. When type TEXT50 it is ECAF89651F429CD3E00AD8B9C8351C32.

Just need to figure out what type to use to get a matching hash.

JB

eddy_declercq
Active Contributor
0 Kudos

I would go for char50. The table is btw always char255 and thus the blanks are calculated with them. Why don't you try the FM Brian proposed earlier in this thread?

Former Member
0 Kudos

Interesting thought!

Brian??? SAP??

eddy_declercq
Active Contributor
0 Kudos

I found an article saying

"In the SAP database, only hash values of the user ID and password information are stored using a slighly modified MD5 hash algorithm. ..." So ther must be something in there and I hope the real MD5 stuff.

I didn't find anything useful at first sight at help.sap.com and when I wanted to look further, their TREX broke (again).

eddy_declercq
Active Contributor
0 Kudos

Stop the presses;-)

Found this code at http://sap.ittoolbox.com/code/d.asp?d=1669&a=s. A reply said that one should better use MD5_CALCULATE_FOR_CHAR instead of FIEB_PASSWORD_ENCRYPT.

The problem is that MD5_... doesn't exist in our 6.4

I found the following FMs though

MD5_CALCULATE_HASH_FOR_CHAR

MD5_CALCULATE_HASH_FOR_RAW

MD5_CONVERT_HASH

MD5_GET_HASH_INTERACTIVE

But which one do I use? Is it the real MD5 stuff (see earlier post)?

Btw the FIEB_PASSWORD_ENCRYPT uses 'Vigenere-Chiffre' (but with a long key) according to the commenst in it.

Eddy

Former Member
0 Kudos

MD5_CALCULATE_HASH_FOR_CHAR I tried that with

CMEHIL

and length 128

Result: D41D8CD98F00B204E9800998ECF8427E

But that doesn't match to simple MD5 convert in PHP??

19c036edebd14b355af79f87abaad276


<?php echo md5("CMEHIL"); ?>

eddy_declercq
Active Contributor
0 Kudos

I think it does indeed not work, since my name, with any length > 0 will give D41D8CD98F00B204E9800998ECF8427E too.

I've been debuging stuff and it's hashing nothing since it's always use the input table, due to this test

IF DATA_TAB IS REQUESTED

Anyway, I've put CMEHIL in the table and I get

A379589096A6FA320D2893DE06AA3FD1

back.

Eddy

Former Member
0 Kudos

Maybe Brian has a thought or two that he can share next time he is online?

eddy_declercq
Active Contributor
0 Kudos

If one creates a report, it'll work fine

data : HASH LIKE MD5_FIELDS-HASH.

CALL FUNCTION 'MD5_CALCULATE_HASH_FOR_CHAR'

EXPORTING

DATA = 'CMEHIL'

  • LENGTH = 0

  • VERSION = 1

IMPORTING

HASH = HASH

  • TABLES

  • DATA_TAB =

EXCEPTIONS

NO_DATA = 1

INTERNAL_ERROR = 2

OTHERS = 3

.

IF sy-subrc <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

else.

write HASH.

ENDIF.

It returns 19C036EDEBD14B355AF79F87ABAAD276

Eddy

Former Member
0 Kudos

Interesting, if I call the function without a length I wonder...

answer: the same as before

eddy_declercq
Active Contributor
0 Kudos

Even if you put it in a report? Length is automaticaly determined if it's 0.

former_member181879
Active Contributor
0 Kudos

Sometime ago we also needed to hash some stuff. A call to the security group recommended that we use function CALCULATE_HASH_FOR_CHAR. From my understanding this is recommended above older MD5 functions. One of the strengths of this new function is that the actual hash string is UTF8 encoded.


  DATA: str  TYPE STRING,
        hash TYPE HASH160.
  CALL FUNCTION 'CALCULATE_HASH_FOR_CHAR'
   EXPORTING data = str
   IMPORTING hash = hash.

eddy_declercq
Active Contributor
0 Kudos

Thanw for the info.