qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aidan Skinner" <ai...@apache.org>
Subject Re: Random .Net question
Date Tue, 03 Jun 2008 16:21:31 GMT
On Tue, Jun 3, 2008 at 5:16 PM, Tomas Restrepo
<tomas.restrepo@devdeo.com> wrote:

>> So, I'm trying to fix QPID-1058 and add CRAM-MD5-HASHED support to the
>> .Net client. I'm having a bit of a problem, which I think is due to
>> the signed vs unsigned nature of byte in java and C#.
>> If I force the key bytes to be within the range 0-127 all is well, but
>> if they go higher of lower then I start getting different outputs from
>> the HMAC, which is a bit perturbing.
>> Don't suppouse anybodys come across something similar before have they?
> Might this be an encoding issue? I.e. how are the bytes for
> calculating the initial hash derived from the plain-text password
> provided by the caller? The encoding should certainly match on both
> sides, otherwise the byte-representation will differ and the hash
> won't match.... Just a thought.

They bytes are generated from the MD5 of the password, which returns
the same hex on both platforms. The problem comes when that byte[] is
passed to the HMACMD5 constructor as the key.

This works (ie. produces the same result as it's java cousin)

byte[] key = new byte[]{0x7F};
HMAC hmac = new HMACMD5(key);
byte[] value = hmac.ComputeHash("foo");

Changing that 0x7F to 0x80 does not.

- Aidan

aim/y!:aidans42 g:aidan.skinner@gmail.com
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."

View raw message