Prev: AES counter content and same key/nonce
Next: Another informative pronouncement from Smug Doug Gwyn
From: Peac on 4 Feb 2010 03:53
I am working on a client server application.
There is one server - it's running on a Windows Machine.
There are multiple clients - some running on Windows, some on Linux etc.
Some client programs may be written in C or C++. The others may be
in Java.

I am going to be using HMACs in my application.
My question is on Windows, I am thinking of using the Microsoft's
APIs & functions.
http://msdn.microsoft.com/en-us/library/aa380252(VS.85).aspx#hash_and_digital_signature_functions

Can I get compatibility for the same in my Java Program. i.e. if the Windows
Native
program generates the HMAC-MD5, will a client written in Java be able to
validate the HMAC computed my the Microsoft APIs & sent over the wire to the
client?

What can I do avoid problems here?


From: Ilmari Karonen on 4 Feb 2010 06:06
On 2010-02-04, Peac <peac1972(a)hotmail_munged.com> wrote:
>
> Can I get compatibility for the same in my Java Program. i.e. if the
> Windows Native program generates the HMAC-MD5, will a client written
> in Java be able to validate the HMAC computed my the Microsoft APIs
> & sent over the wire to the client?

I don't see any reason it shouldn't. There's nothing ambiguous about
the definition of HMAC-MD5, so the result should be the same on any
platform. Of course, it's always prudent to test such things, but I
would be quite surprised if there were any incompatibilities.

(What might cause incompatibilities are changes in the data itself.
For example, if you take some Unicode text in the UTF-8 encoding and
convert it to UTF-16, the MAC will obviously change. Even just
changing the representation of line breaks from CR/LF to LF, or vice
versa, is enough to make the MAC completely different.)

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
From: Peac on 5 Feb 2010 03:38

"Ilmari Karonen" <usenet2(a)vyznev.invalid> wrote in message
news:slrnhmlaic.eet.usenet2(a)melkki.cs.helsinki.fi...
> On 2010-02-04, Peac <peac1972(a)hotmail_munged.com> wrote:
>>
>> Can I get compatibility for the same in my Java Program. i.e. if the
>> Windows Native program generates the HMAC-MD5, will a client written
>> in Java be able to validate the HMAC computed my the Microsoft APIs
>> & sent over the wire to the client?
>
> I don't see any reason it shouldn't. There's nothing ambiguous about
> the definition of HMAC-MD5, so the result should be the same on any
> platform. Of course, it's always prudent to test such things, but I
> would be quite surprised if there were any incompatibilities.

Thanks everyone for your help. I have this code working between 2 Native
C Programs. However, as I suspected the Java stuff doesn't match.

From googling it looks like the Microsoft Crypto API function CryptDeriveKey
is the problem. I call this function to derive a key from my password.

The MSDN sample is here
http://msdn.microsoft.com/en-us/library/aa382379(VS.85).aspx

From the comments.
// Derive a symmetric key from a hash object by performing the
// following steps:
// 1. Call CryptCreateHash to retrieve a handle to a hash object.
// 2. Call CryptHashData to add a text string (password) to the
// hash object.
// 3. Call CryptDeriveKey to create the symmetric key from the
// hashed password derived in step 2.

It looks like CryptDeriveKey is some MS Specific algorithm.
What can I do instead to derive a key from the password which
can be replicated in Java portability.



From: Ilmari Karonen on 5 Feb 2010 05:08
On 2010-02-05, Peac <peac1972(a)hotmail_munged.com> wrote:
> "Ilmari Karonen" <usenet2(a)vyznev.invalid> wrote in message
> news:slrnhmlaic.eet.usenet2(a)melkki.cs.helsinki.fi...
>> On 2010-02-04, Peac <peac1972(a)hotmail_munged.com> wrote:
>>>
>>> Can I get compatibility for the same in my Java Program. i.e. if the
>>> Windows Native program generates the HMAC-MD5, will a client written
>>> in Java be able to validate the HMAC computed my the Microsoft APIs
>>> & sent over the wire to the client?
>>
>> I don't see any reason it shouldn't. There's nothing ambiguous about
>> the definition of HMAC-MD5, so the result should be the same on any
>> platform. Of course, it's always prudent to test such things, but I
>> would be quite surprised if there were any incompatibilities.
>
> Thanks everyone for your help. I have this code working between 2 Native
> C Programs. However, as I suspected the Java stuff doesn't match.
>
> From googling it looks like the Microsoft Crypto API function CryptDeriveKey
> is the problem. I call this function to derive a key from my password.

Hmm. Internally, the keys to HMAC-MD5 are 512 bit strings. According
to RFC 2104, if the supplied key is shorter than 512 bits, it should
be padded with zeroes to the full length, while a longer key should be
first hashed and then padded.

It seems Microsoft is doing something else; from what I could tell by
looking at the docs, it looks like they might simply be always hashing
the key, but I couldn't find anything really definite about what goes
on under the hood. You could test it with keys longer than 512 bits
and see if they give the same results then.

I'm not sure if there's any way to make the Microsoft implementation
behave in an RFC-compliant manner. If not, you could always implement
the HMAC construction yourself. It's not very difficult. In
pseudo-Java/C#:

byte[64] ipad = ((byte) 0x5c).repeat(64);
byte[64] opad = ((byte) 0x36).repeat(64);

byte[16] HMAC_MD5 (byte[] key, byte[] input) {
if (key.length > 64) {
MD5Hash keyHash = new MD5Hash ();
keyHash.addData(key);
key = keyHash.getResult();
}
byte[64] expKey = key.padToLength(64);

MD5Hash innerHash = new MD5Hash ();
innerHash.addData(key.xor(ipad));
innerHash.addData(input);
byte[16] temp = innerHash.getResult();

MD5Hash outerHash = new MD5Hash ();
outerHash.addData(key.xor(opad));
outerHash.addData(temp);
return outerHash.getResult();
}

That's off the top of my head, but I think it should do it unless I've
made some silly mistake.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
From: Tom St Denis on 5 Feb 2010 07:45
On Feb 4, 3:53 am, "Peac" <peac1972(a)hotmail_munged.com> wrote:
> I am working on a client server application.
> There is one server - it's running on a Windows Machine.
> There are multiple clients - some running on Windows, some on Linux etc.
> Some client programs may be written in C or C++. The others may be
> in Java.
>
> I am going to be using HMACs in my application.
> My question is on Windows, I am thinking of using the Microsoft's
> APIs & functions.http://msdn.microsoft.com/en-us/library/aa380252(VS.85).aspx#hash_and...
>
> Can I get compatibility for the same in my Java Program. i.e. if the Windows
> Native
> program generates the HMAC-MD5, will a client written in Java be able to
> validate the HMAC computed my the Microsoft APIs & sent over the wire to the
> client?
>
> What can I do avoid problems here?

Why not just use an OSS crypto library that is portable? The Windows
CSP API is fairly awful.

Tom
 |  Next  |  Last
Pages: 1 2
Prev: AES counter content and same key/nonce
Next: Another informative pronouncement from Smug Doug Gwyn