http://bugs.winehq.org/show_bug.cgi?id=20340
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2009-10-21 16:20:38 --- With current Wine, the failures are: [ RUN ] HMACTest.RFC2202TestCases [8:9:1021/141210:491:FATAL:hmac_win.cc(70)] Check failed: false.
and: [ RUN ] HMACTest.HMACObjectReuse [8:9:1021/141211:1254:FATAL:hmac_win.cc(70)] Check failed: false.
Those failures are on the following line: if (!CryptImportKey(plat_->provider_, &key_blob_storage[0], key_blob_storage.size(), 0, CRYPT_IPSEC_HMAC_KEY, &plat_->hkey_)) { NOTREACHED();
That is, the key isn't imported. From a +crypt trace: trace:crypt:CryptImportKey (0x1528c8, 0xca7bb8, 32, 0x0, 00000100, 0xca7b88) trace:crypt:RSAENH_CPImportKey (hProv=00000001, pbData=0xca7bb8, dwDataLen=32, hPubKey=00000000, dwFlags=00000100, phKey=0x152abc) trace:crypt:import_key blob type: 8 trace:crypt:new_key alg = "RC2", dwKeyLen = 160 trace:crypt:new_key key len 160 out of bounds (5, 128)
That is, even the current key length limit of 128 is insufficient to make the app happy. Applying the following hacky patch to rsaenh: diff --git a/dlls/rsaenh/rsaenh.c b/dlls/rsaenh/rsaenh.c index 1b23391..de6da03 100644 --- a/dlls/rsaenh/rsaenh.c +++ b/dlls/rsaenh/rsaenh.c @@ -159,7 +159,7 @@ typedef struct tagKEYCONTAINER static const PROV_ENUMALGS_EX aProvEnumAlgsEx[5][RSAENH_MAX_ENUMALGS+1] = { { - {CALG_RC2, 40, 5, 128,0, 4,"RC2", 24,"RSA Data + {CALG_RC2, 40, 5, 640,0, 4,"RC2", 24,"RSA Data {CALG_RC4, 40, 40, 56,0, 4,"RC4", 24,"RSA Data {CALG_DES, 56, 56, 56,0, 4,"DES", 31,"Data Enc {CALG_SHA, 160,160, 160,CRYPT_FLAG_SIGNING, 6,"SHA-1", 30,"Secure H
results in the following sorts of errors instead: [ RUN ] HMACTest.RFC2202TestCases .\hmac_unittest.cc(129): error: Value of: 0 Expected: memcmp(cases[i].digest, digest, kDigestSize) Which is: 1
That is, just adjusting the key length limit results in the hash producing bad values. I believe the problem is the lack of HMAC support in rsaenh. libtomcrypt, on which rsaenh was built, has an HMAC implementation, but it wasn't included as part of rsaenh.
I believe reverting Dmitry's patch is more correct than leaving it in, and I sent some patches to do so. This one's going to need more work.