|
Hi Tim
Again, thanks for your reply
I am at the site that you suggested that I read, and I am looking at the different test scenarios.
One thing that I immediately notice for example
4.2. Test Case 1
Key = 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b (20 bytes)
Data = 4869205468657265 ("Hi There")
HMAC-SHA-224 = 896fb1128abbdf196832107cd49df33f
47b4b1169912ba4f53684b22
HMAC-SHA-256 = b0344c61d8db38535ca8afceaf0bf12b
881dc200c9833da726e9376c2e32cff7
HMAC-SHA-384 = afd03944d84895626b0825f4ab46907f
15f9dadbe4101ec682aa034c7cebc59c
faea9ea9076ede7f4af152e8b2fa9cb6
HMAC-SHA-512 = 87aa7cdea5ef619d4ff0b4241a1d6cb0
2379f4e2ce4ec2787ad0b30545e17cde
daa833b7d6b8a702038b274eaea3f4e4
be9d914eeb61f1702e696c203a126854 What format is
Data = 4869205468657265 ("Hi There")
Forgive me if this is an obvious answer as I have already been working
9 hours (on production problems) And I have to go to 3 more separate
meetings before I can go home 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
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tim Bronski
Sent: Saturday, January 26, 2013 9:14 AM
To: Midrange Systems Technical Discussion
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.
Need secure FTP? Forget PASE...get your FREE sFTP here
www.arpeggiosoftware.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
