erpdude8, on 13 November 2010 - 04:25 AM, said:
that's because the 128-bit versions of IE 5.01 SP, IE 5.5 and IE 6.0 install 128-bit versions of the RSAENH.DLL & SCHANNEL.DLL files and NOT the 128-bit version of the SECUR32.DLL file. Installing/upgrading to the 128bit encryption edition of IE does not upgrade the SECUR32.DLL file to 128-bit version.
Thanks for that info. It explains why IE can have 128 bit encryption despite SECUR32.DLL.
erpdude8, on 13 November 2010 - 04:25 AM, said:
Yeah! That's pretty similar to what I'm facing now. Pity there was no resolution.
herbalist, on 13 November 2010 - 02:16 PM, said:
I'm not sure if this is any help or if it confuses the situation even more. On my old 98FE unit, my copy of secur32.dll does not say export version or USA and Canada on the version tab. Just says Microsoft Win32 Security Services.
The MD5 for the file is 677273be08256ea12afdfc8da91ac54a if it's of any help. So far, I'm unable to determine just where I got this file. It does have DUN1.4 installed.
That's right, older versions of SECUR32.DLL do no differentiate Export vs US/Canada sub-versions. I think that's because this was before the 128 bit encryption for NTLMv2 was added. So only newer versions have that split.
PROBLEMCHYLD, on 13 November 2010 - 05:01 PM, said:
Quote
How to get 128-bit secur32.dll file...
In tinkering with a factory-state Dell with Win98 SE, I've discovered that having IE6 with 128bit (only that app upgraded after factory-state) somehow isn't what the dsclient9x.msi wants when deciding which version of secur32.dll to give you (56bit or 128). With IE6 you'll get 56. However, when I went back to true factory state and then installed the "high encryption pack" version of IE, version 5 for Win98, followed by execution of dsclient9x.msi, I then ended up with the 128-bit version of secur32.dll. Be cautious, however, since I've found Microsoft documentation on the Web that indicates that subsequent hot fixes can destroy what dsclient9x.msi sets up. Sorry to not include links. I don't have them handy but this information should be easy to find with simple searches on key words/phrases within this text.
Yes, I encountered this too, which is the reason why I've tried this on W98 machines with both IE6 and IE5, as it is implied that the DSClient install incorrectly determines the encryption capabilities of IE6. However, I didn't get any different result in either case.
----------------------------
The KB's suggest that the DSClient installer package checks the security capability (56 vs 128 bit encryption) of your IE installation, to decide if you qualify for the 56 bit (Export) or 128 bit (US/Canada) capable sub-versions of SECUR32.DLL. But as usual, it seems the detection logic is faulty, and nothing I've tried so far has been successful. Now that 128 bit NTLMv2 is becoming mandatory (by default), this is a real problem.
The alternative theory is that all the stuff in the KB's describing these two sub-versions is pure fantasy. That's why I question if anyone has ever seen the 128 bit version of SECUR32.DLL as described (ie. identified as "(US and Canada only)" in its version description). I guess that version description comes from the time when 128 bit encryption software was restricted to USA and Canada (I can't recall when that restriction eased, although it must have been around the time of IE 5.5).
The various DSClient installer packages seem to contain only the "Export" version of SECUR32.DLL when you open them with TugZip or 7Zip. Different versions seem to exist for W95, W98 and W98SE. Perhaps the "US and Canada only" sub-version is produced by the DSClient installer by patching the "Export" version.
The only new lead I've encountered in the past day or so, is that the Q323466 update for DSClient (not clear from the archived KB just what that update fixes) is (also?) included in a file called "5234_ENU_i386_zip.exe". Haven't been able to locate it, nor do I know if it will be any better at producing the 128 bit version of SECUR32.DLL.
Joe.
This post has been edited by jds: 13 November 2010 - 11:24 PM