Re: HMAC calculation -- MIDRANGE-L

My wife is threatening divorce if I don't spend this weekend with her for a change

Some might consider that an opportunity rather than a threat.

And when you're running these tests, remember that the key size for sha256 is 64 bytes and if the key is shorter (as it is in some tests) pad to the right with nulls (x'00's).

On 1/26/2013 5:17 PM, Alan Shore wrote:

Thanks for your reply Tim
I will use your suggestions on Monday
My wife is threatening divorce if I don't spend this weekend with her for a change
The xml is being translated
My description could have been better
Its going to a company called the logic group

----- Original Message -----
From: Tim Bronski [mailto:tim.bronski@xxxxxxxxx]
Sent: Saturday, January 26, 2013 09:14 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: HMAC calculation

Firstly, have you verified your hmac code? If not go here and test
against the vectors provided.
https://tools.ietf.org/html/rfc4231 (i.e use the test data and keys and
check you get the correct output).

If you've got that ok....I'd be concerned when you say you're providing
the xml in EBCDIC. Somewhere I'm certain it's being xlated. Your mac
needs to be calculated over the EXACT same binary stream as it is on the
remote end. Having it xlated in two different places is asking for
trouble. The key should be the same bit string on either end too.

Can I ask who you're sending this to?

On 1/25/2013 10:44 PM, Alan Shore wrote:

Hi everyone
Hopefully someone will take pity on me and provide some answers
(I'm trying to get the sympathy vote)
Before I forget, as I usually do, we are on V5r4.

As part of a web service, I have to provide an authentication token which
"is calculated using the HMAC (keyed-Hash Message Authentication Code) algorithm. This is a type of message authentication code (MAC) calculated using a specific algorithm involving a cryptographic hash function in
combination with a secret key (the shared secret)."
The result of this is to be Hex encoded
What I have done is used the API Qc3CalculateHMAC for SHA_256 (prior e-mail submitted and people have graciously responded)
The result of this calculation is then to be Hex encoded, so I have then used a service program that utilizes
QtqIconvOpen, iconv and iconv_close.
The transmission of this data is being rejected due to the HMAC hex encoded field being incorrect.
I then discovered that the site I am transmitting to is "a Linux system so we are working in ASCII. Use UTF-8." As I was told.
So I thought that I would need to covert the string (and the secret shared password) into the API Qc3CalculateHMAC into UTF-8 (CCSID 1208) - then use the service program that utilizes
QtqIconvOpen, iconv and iconv_close.
However, the rest of the web_service transmission contains EBCDIC values, so I assumed that the Hex encoded value had to be converted BACK to EBCDIC so that the XML transmission would ALL be in EBCDIC to be translated to UTF-8 as part of the transmission
To cut a LOOOOOOOOONG story short, I have tried so many permutations and combinations of what is to be iconved before and after the Qc3CalculateHMAC I don't know where I am
Needless to say ALL of my test transmissions have failed
If anyone has a clearer had than me (who hasn't) and can point me in a good direction, I would be VERY grateful.

Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

Disclaimer: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.