Thanks, Mr. David Roberts

[Clay Clear]

Thanks for that HMac code you posted in the Source Code Forum. I have no intention of using the WinAPI for my security stuff, as I don't trust MS that far, but analyzing your code gives me notions about how hmac is implemented. I have put the functionality in my hash stuff in my DLL, and so far, so good. My next step is to compare my code's output with the output of your code (obviously, can only do this for the MD5 and SHA1 hashes) and tweak my stuff until it would seem that my implementation conforms to the standards.

Thanks again.

[Clay Clear]

<chuckle> It turns out my original implementation was flawed. If I had read your commenting, David, I would've avoided the problem. <sheepish grin> Anyway, everything's peachy keen, now. Thanks, again.

[David Roberts]

Hi Clay

> I have no intention of using the WinAPI for my security stuff, as I don't trust MS that far

Yeah, but I'm only using the API hash not the HMAC. For personal use you could use your own ipad and opad provided that they are Hamming distance optimized. That would give a hacker a bad hair day.

I am currently looking at d-HMAC proposed here.

Mohannad Najjar has given the OK to play around with the method. Quote: "You can use the algorithm."

As is the algorithm takes about twice as long as HMAC. However, a slight tweak of the HMAC protocol doubles the speed bringing it into the same ball park as HMAC which is in the same ball park as a straight Hash for sufficiently large messages - and not that large.

In a few days I should be in a position to drop something into the Source Code forum.

d-HMAC introduces a receiver key in addition to a sender key. As you probably know updating DNS servers implements HMAC-MD5. So, the message integrity is verified along with the authenticity of the sender. With d-HMAC the intended recipient can also be qualified. Oops, the message is OK, you are who you say you are but that wasn't meant for me was it. Powerful stuff.

> Anyway, everything's peachy keen, now.

Magic.

Added: BTW, have you had a look at HashFile. You can check your HMAC values. I've spent a few hours throwing test vectors at it from the Nessie project and it is behaving itself. HashFile.

[Clay Clear]

Thanks for the heads up on that stuff, David. Am looking forward to trying out your d-hmac code once you post it. I will give that "hashfile" stuff a shot, but I don't know when. It will be in the next few days.

[David Roberts]

I've just had the wind taken out of my sails.

> As is the algorithm takes about twice as long as HMAC. However, a slight tweak of the HMAC protocol doubles the speed bringing it into the same ball park as HMAC ...

Getting away from the keyboard I put pen to paper and showed that my 'slight tweak' washed away the collision resistance of the HMAC reducing it to exactly that of the underlying hash. In other words break the hash and down goes the tweaked HMAC. I wasn't tweaking the HMAC per se but in the context of a revised d-HMAC. It was a worthwhile exercise because no where have I seen why the HMAC format is as it is. I now know why.

Anyway, I will still drop something into the Source Code forum re d-HMAC.