"Aging RPGer in need of assistance... "
I'm a newbie to the forum, however when I've needed some inspiration or pointers over the years
to solve an issue I've checked out Scott's site
Recently tasked with developing a "hashing" pgm (to generate a SHA-256 key) to secure some payment files for upload to external portals
which is completely new diversion from my usual ERP programs that I develop
Developed a program based on numerous articles that I've found searching the internet.
Pgm reads the physical file (single field records, containing XML tags/data) and it generates a hash value
(which a 3rd party, who will process the file confirm it as a usable hashvalue by them)
I've now had a new request...from a different organisation, that the "hashing value" should contain "lowercase only"...?
I did try the "iConv sample program" in the "HMAC Hash Code" thread on this site, with the sample values provided by "imaxeman69",
but I got a similar result to the ": B9CE6D6CD31217B36602195872029B3B020C9241D6951F6023E058C504E7C9E0" and not the lowercase Postman result quoted...I've obviously missed something in there as well
Can anyone advise how I can achieve the desired result...
I think I may need more translating/conversion than I currently have, or possibly different API?
SHA-256 "lower case" value
-
- Site Admin
- Posts: 794
- Joined: Sun Jul 04, 2021 5:12 am
Re: SHA-256 "lower case" value
I'm not sure that I follow you. What part is meant to be lowercase only?
What is your question? How to translate something to lowercase?
What is your question? How to translate something to lowercase?
-
- Posts: 3
- Joined: Tue Apr 11, 2023 8:25 am
Re: SHA-256 "lower case" value
Hi Scott,
Apologies for delay in replying, unfortunately life throws things at us out the blue sometimes,
which overtakes everything else we're doing
Anyway I'll try to put some more meat on the bone...
I've run my program (above) with a set of sample data in a physical file
Rcds (1-7, 1500A)
<?xml version="1.0" encoding="UTF-8" ?>
<employees>
<employee>
<id>1</id>
<firstName>Tom</firstName>
</employee>
</employees>
These are the results I can see when running it thru debug
(EBCDIC > NO pre-translate to ASCII)
returned HASHVALUE =
....5...10...15...20...25...30...35...40...45...50...55...60
1 '^■ÿwÖ■±■■■■+■D¾■è■&õ $µY?÷Å à■åÙ '
61 ' '
Then call
base64_encode( %addr(HashValue)
: %len(HashValue)
: %addr(OutValue)
Returned OUTVALUE =
....5...10...15...20...25...30...35...40...45...50...55...60
1 'uj7fpuwpjyQ9MhNOC8S5J1QDUM8ASqDob+FnD0QpR/1AQEBAQEBAQEBAQEBA
61 'QEBA'
When I run the same sample data thru 2 on-line converters I get the following hashvalue
On-line SHA256 (multiple sites give result below)
lowercase
0b253401de4b55e51485afad96aae6646863603e792e73b3ae380f2ecf57dc67
UPPERCASE
0B253401DE4B55E51485AFAD96AAE6646863603E792E73B3AE380F2ECF57DC67
My Q? is what am I missing/not doing in my program to achieve the same value?
Hope this makes my confusion clearer...
Apologies for delay in replying, unfortunately life throws things at us out the blue sometimes,
which overtakes everything else we're doing
Anyway I'll try to put some more meat on the bone...
I've run my program (above) with a set of sample data in a physical file
Rcds (1-7, 1500A)
<?xml version="1.0" encoding="UTF-8" ?>
<employees>
<employee>
<id>1</id>
<firstName>Tom</firstName>
</employee>
</employees>
These are the results I can see when running it thru debug
(EBCDIC > NO pre-translate to ASCII)
returned HASHVALUE =
....5...10...15...20...25...30...35...40...45...50...55...60
1 '^■ÿwÖ■±■■■■+■D¾■è■&õ $µY?÷Å à■åÙ '
61 ' '
Then call
base64_encode( %addr(HashValue)
: %len(HashValue)
: %addr(OutValue)
Returned OUTVALUE =
....5...10...15...20...25...30...35...40...45...50...55...60
1 'uj7fpuwpjyQ9MhNOC8S5J1QDUM8ASqDob+FnD0QpR/1AQEBAQEBAQEBAQEBA
61 'QEBA'
When I run the same sample data thru 2 on-line converters I get the following hashvalue
On-line SHA256 (multiple sites give result below)
lowercase
0b253401de4b55e51485afad96aae6646863603e792e73b3ae380f2ecf57dc67
UPPERCASE
0B253401DE4B55E51485AFAD96AAE6646863603E792E73B3AE380F2ECF57DC67
My Q? is what am I missing/not doing in my program to achieve the same value?
Hope this makes my confusion clearer...
-
- Site Admin
- Posts: 794
- Joined: Sun Jul 04, 2021 5:12 am
Re: SHA-256 "lower case" value
The difference seems to be that you are base64 encoding it, whereas the online converters you cite are outputting hex strings instead of base64 encoding.
If you translated the base64 letters to lowercase, you'd change their meaning -- so don't do that.
But if you output data in hex instead, you can change it to upper or lowercase without affecting it's meaning.
But the really fundamental difference is the difference between base64 vs. hex. They are completely different things.
If you translated the base64 letters to lowercase, you'd change their meaning -- so don't do that.
But if you output data in hex instead, you can change it to upper or lowercase without affecting it's meaning.
But the really fundamental difference is the difference between base64 vs. hex. They are completely different things.
-
- Posts: 3
- Joined: Tue Apr 11, 2023 8:25 am
Re: SHA-256 "lower case" value
Hi Scott,
I've stopped the encoding in my program, and doing a conversion to hex using the "cvthc" API
after running the "accumulated" records thru the 'Qc3CalculateHash' API
I'm just wondering if the CCSID could also impact the hashing value??
The file I'm using has 65535 as the CCSID...
I've stopped the encoding in my program, and doing a conversion to hex using the "cvthc" API
after running the "accumulated" records thru the 'Qc3CalculateHash' API
I'm just wondering if the CCSID could also impact the hashing value??
The file I'm using has 65535 as the CCSID...
-
- Site Admin
- Posts: 794
- Joined: Sun Jul 04, 2021 5:12 am
Re: SHA-256 "lower case" value
65535 isn't a CCSID -- it's a special value that means *HEX (i.e. the customer knows what the encoding is, but the OS doesn't -- so don't translate it.)
The hash is calculated based on the binary value that you pass to the Qc3CalculateHash API. So if the remote site is expecting, for example, the hash to be calculated on UTF-8 data, and your data is in EBCDIC, the hash will definitely not match.
You need to make sure you translate the data before calling Qc3CalculateHash -- make sure it is translated to the same character set th remote site expects.
The hash is calculated based on the binary value that you pass to the Qc3CalculateHash API. So if the remote site is expecting, for example, the hash to be calculated on UTF-8 data, and your data is in EBCDIC, the hash will definitely not match.
You need to make sure you translate the data before calling Qc3CalculateHash -- make sure it is translated to the same character set th remote site expects.