If you try to use any SHA-2 algorithm (SHA-256, SHA-384 and SHA-512) on Windows XP, you may get the following error when using i.e. CryptCreateHash: NTE_BAD_ALGID or -2146893816 or 0x80090008 or "Invalid algorithm specified". Same algorithms are supported on Vista, though.
Can we use SHA-2 algorithms in Windows XP at all? The answer is yes, but it will depend on the CSP (Cryptographic Service Provider) that we use to perform the cryptographic operations.
According to our documentation, Windows XP SP3 supports all SHA-2 algorithms except SHA-224:
Overview of Windows XP Service Pack 3 "Implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in X.509 certificate validation. This has been added to the crypto module rsaenh.dll."
Our "Microsoft Base/Strong/Enhanced Cryptographic Providers" are implemented on Rsaenh.dll. If you try to use CryptCreateHash with any SHA-2 Algid (CALG_SHA_256, CALG_SHA_384, CALG_SHA_512) and any of these CSP, you will still get a NTE_BAD_ALGID error on XP SP3. Why? The issue is that those Algid's are only valid with providers of type PROV_RSA_AES, and these CSP are of type PROV_RSA_FULL.
"Microsoft Enhanced RSA and AES Cryptographic Provider" (or "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)" as it's called on Windows XP SP3) is implemented in rsaenh.dll and is of type PROV_RSA_AES.
Note that technically speaking, Microsoft AES Cryptographic Provider is just Microsoft Enhanced Cryptographic Provider with support for AES encryption algorithms.
If you open regedit.exe and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults, you will be able to see the available Providers in the system ("Microsoft Enhanced Cryptographic Provider v1.0", "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)", etc.) and the Provider Types ("Type 001" which is "RSA Full (Signature and Key Exchange)", "Type 024" which is "RSA Full and AES"). For each Provider you will also see which dll implements (rsaenh.dll, etc.) it and its Provider Type (1, 24, etc.). For each Provider Type you will see the name of the default Provider for that type. On Vista, default Provider for PROV_RSA_AES is "Microsoft Enhanced RSA and AES Cryptographic Provider", and on XP is "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)".
Regarding SHA-224 support, SHA-224 offers less security than SHA-256 but takes the same amount of resources. Also SHA-224 is not generally used by protocols and applications. The NSA's Suite B standards also do not include it. We have no plans to add it on future versions of our CSPs.
Fortunately, Microsoft's CryptoAPI is based on a model which allows us to use any CSP which implements any algorithm. So we don't and won't implement SHA-224 in our own CSPs, but that doesn't mean that we can't use SHA-224 at all on Windows. We just need a third-party CSP which implements it, or create our own.
I hope this helps.
Alex (Alejandro Campos Magencio)
Does this mean that both sets of CSPs are implemented in the rsaenh.dll file? Just that within that DLL there are selectable provider types: PROV_RSA_AES(which DOES work with the new algorithms) and PROV_RSA_FULL( which does NOT)? So though the same DLL is responsible for delivering the functionality of the provider you choose, it does make a difference on which one you select?
Yes, that is exactly what it means.
I need some help on AES supports for XP. I am using XP SP3 with outlook SP2. I tried to choose AES for the email encryption under the Trust Centre setting.
I cannot find AES option and there is only 3DES.
I also notice that AES option is available on another machine with Vista and Windows 7 for the same outlook 2007 SP2.
Wonder if there is any registry that I need to do ? I checked and found that there is an entry for AES in my registry.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)
I really have no idea how Outlook 2007 works under the scenes. Maybe the "(Prototype)" part of the name is confusing it... You may want to open a Support case with our Outlook team...
"Fortunately, Microsoft's CryptoAPI is based on a model which allows us to use any CSP which implements any algorithm. So we don't and won't implement SHA-224 in our own CSPs, but that doesn't mean that we can't use SHA-224 at all on Windows. We just need a third-party CSP which implements it, or create our own."
This is not true. If you try to use CryptMsgOpenToEncode and specify SHA-224 (for instance), you'll get an error even if your CSP supports the algorithm. The CryptoApi doesn't even check your CSP for supported algorithms (through CryptGetProvParam(PP_ENUMALGS)) it still uses the PROV_RSA_FULL CSP no matter which CSP handle you specified (this is also written in the API documentation on MSDN)
Thx FrizzTheSnail, that is interesting. I don't have a CSP that supports SHA-224, so I cannot try this. Does it happen with basic Crypto functions (not just with CryptMsg*)?
I'm not that expert :p
It depends by the OS layer between the Crypt*** function you make from application level and the CP*** function which is called in the CSP. There are functions which check the ALGID you're using.
In my knowledge the problematic functions are CryptOpenMsgToEncode and CryptMsgOpenToDecode, which is quite a trouble because when managing CAPI messages you have to pass by these.
CryptMsgOpenToDecode, for instance, blocks elaboration immediately when it finds an unsupported algorithm in the pkcs7 header, regardess of the CSP supported algs. The silly thing is: if the hash alg is for instance SHA-1, CryptMsgOpenToDecode calls the specified CSP for the hash calculation; so the function's limit is just in internal controls. There might be reasons behind this choice, but it would be enough to remove some ALID controls in the CryptMsgOpenToEncode/Decode stubs to allow them to work exactly as stated by MS :)
As for straightforward functions like CryptCreateHash, CryptMsgUpdate, which are simplier stubs of the correspnding CSP calls there is no problem.
PS: Yes, you'd need your own CSP, and a machine configuration that supports loading of "unsigned" CSPs to test this for real (in Debug mode), which is quite tricky...
My CA is a Windows 2003 Enterprse
I created a template by using "Microsoft Enhanced RSA and AES Cryptographic Provider".
When I tried to get SHA512 Certificate by using that am getting error of "Your Request Id is 0. The disposition message is "Error Verifying Request Signature or Signing Certificate Invalid algorithm specified. 0x80090008 (-2146893816)". "
Am already applied path WindowsServer2003-KB968730-x86-ENU.exe
can you give me any clue how can I get sha-2 certifiate from my 2003 CA ?
I'm trying to use SHA256 on windows xp sp3 but it doesn't work. I would like to use it in digital signature verification with Capicom. As said in previous comment Microsoft is not supporting this type of algorithm on Windows XP.
Could it be possible that in short time there will be a patch fixing this?
Does anyone know if there is an alternative way to use SHA256 on XP?
Which CSP are you using? I've been able to use SHA-2 on XP SP3 with "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)"
Hi Alex. I use Capicom activex interface (from Visual Basic 6.0 code). If the signed envelope uses SHA1 as hash algorithm all it's well, but when is signed using SHA256 capicom on xp says "algorithm not supported". I don't know of which CSP capicom internally uses. Do you think that if I try to use directly CSP with CryptoApi (or .NET Cryptography services) I could solve my problem?
I've never tried SHA-2 with CryptMsg on XP, not sure 100% if it will work. It works with CryptAcquireContext and other CAPI1 functions if you use the proper CSP, but not sure about CAPI2 functions like CryptMsg*.
If you use .NET, note that you won't be able to use SHA-2 on Vista and later. Vista and later only support SHA-2 with CNG providers when dealing with CMS, and .NET doesn't support CNG providers yet. So on Vista and later you have to use CryptMsg and a CNG cert. But XP has no CNG, so I don't know for sure if it will work.
I would need to try all this to know for sure. If you need help with this, I suggest you open a case with Microsoft Tecnical Support.
we are using windowsxp and sp3...we are using java methods and using xenroll.dll....we want to generate sha256 request and we hav chosen Microsoft Enhanced RSA and AES Cryptographic Provider.
we are getiing error in requets generation
How to detect SHA-2 algorithm supported OS.
I am Krish from UK. I have few question over Microsoft CNG B crypt API it will be great if you can add some light on the same. it will really helpful for my team as well.
1) How to test the B Crypt API with different algorithm provider? I mean how to the functional test and performance test and stress test of the same do we have any tools or any client code that we can use for testing ?
2) do we have any bench mark performance numbers or that we can compare with our algorithm provider ?
3) if we want to write our own client client to test the same what is the procedure which client is best C++ PHP?