Sha256 для windows xp

First published on TECHNET on Sep 30, 2010

UPDATE (2/8): Based on some recent questions, additional information has been posted about SHA2 and Windows.

We’ve recently received a couple of requests from customers around the functionality of SHA-256 when running on Windows XP and 2003. This has been more important recently, as NIST has recommended the migration off of SHA-1 by end of the year. More details about the NIST recommendation can be found in SP 800-78-2 and SP 800-57 . Hopefully this blog post can help clear up the confusion surrounding scenarios that work and the ones that don’t.

Prior to Windows XP Service Pack 3, there was no SHA2 functionality within Windows XP. With the release of Service Pack 3 some limited functionality was added to the crypto module rsaenh.dll. This includes the following SHA2 hashes: SHA-256, SHA-384, SHA-512. SHA-224 was not included.

Windows Server 2003 Service Pack 2 does not ship with support for SHA2. This limitation can become an important concern when processing smart card logons and for mutual TLS authentications to web servers. As unlike other technologies, smart card logon and mutual TLS both use strict revocation checking; so should either the certificate itself or the revocation information (CRL/OCSP) use SHA2, the logon would fail.

Though support SHA2 is not included in Windows Server 2003 Service Pack 2, it is available for download. KB 938397 will bring Windows Server 2003 to the same level of functionality as Windows XP with Service Pack 3. KB 938397 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page . Note, KB 938397 is also offered for Windows Server 2003 Service Pack 1.

With the release of Windows Server 2008 it was found that Windows XP Service Pack 3 and Windows Server 2003 Service Pack 2 with KB 938397 were unable to request certificates from a Windows Server 2008 (and 2008 R2) certificate authority (CA) who’s certificate was signed with a SHA2 hash. KB 968730 was release to address this issue. Incidentally, KB 968730 completely supersedes KB 938397; so if a Windows Server 2003 Service Pack 2 system would need to both enroll from a SHA2 certificate authority and process SHA2 certificates, only KB 968730 would need to be installed. As before, KB 968730 is not available via Windows Update; it needs to be requested via the “View and request hotfix downloads” link on the support page . Note, KB 968730 is not offered for Windows Server 2003 Service Pack 1.

Starting with Windows Vista and Server 2008, the Cryptography Next Generation (CNG) Suite B algorithms (including SHA2) are included in the operating system. It is worth noting that even though the algorithms are available, it is up to the individual applications to implement support.

Besides logon, another very popular use for smart cards is S/MIME. But before diving into Outlook and S/MIME, the following warning should be given: Regardless of the functionality Windows and Outlook provide; in order for mail to be delivered between two users, there are any number of spam filters, relays, mailboxes, etc between sender and recipient. Each of these can be made by a wide range of vendors; running on a wide range of platforms. So before deploying SHA2, testing should be done against one’s own email infrastructure, in addition to the email infrastructure of external organizations from whom S/MIME signed mail needs to be exchanged with.

All those warnings aside, the basic functionality for Outlook is a follows. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 can sign and validate certificates when that certificate itself is SHA2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate email messages when the message itself is SHA2 signed (regardless of the certificate used). Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot sign a message with SHA2; only SHA-1 and MD5 are available.

In order to validate SHA2 messages, Windows Vista with Outlook 2003 (or newer) is needed. In order to both sign and validate SHA2 messages, Windows Vista or 7 with Outlook 2007 or 2010 is needed.

For organizations looking to deploy SHA2 or organizations that interact with 3 ^rd parties that will soon begin using SHA2, the following is recommended.

• If Windows XP is used in the environment, Service Pack 3 should be deployed. In addition to SHA2 functionality, Service Pack 3 is currently the only Windows XP service pack that is supported.

• If Windows XP systems would need to enroll in certificates from a SHA2 certificate authority, KB 968730 should be deployed.

• If Windows Server 2003 is used in the environment, Service Pack (1 or 2) and KB 938397 should be deployed.

• If Windows Server 2003 would need to enroll in certificates from a SHA2 certificate authority, Service Pack 2 and KB 968730 should be deployed. If planning on deploying KB 968730, installing KB 938397 is not necessary.

• If S/MIME using SHA2 signing for the message body is needed, workstations should be upgraded to at least Windows Vista running Office 2003.

-Adam Stasiniewicz

UPDATE (2/8): Based on some recent questions, additional information has been posted about SHA2 and Windows.

Feb 12, 2025

Introduction

Index:

1. OS,   Browser, and Server Support
2. Firewall Support
3. Toolkits, Libraries, Frameworks, etc.
4. Database Support
5. Detailed Operating System Support
6. E-Mail Clients
7. Document Signing
8. Windows Code Signing
9. SafeNet iKey / eToken Compatibility
10. Mainframe
11. Citrix Support
12. Services

OS, Browser, and Server Support  

Firewall Support

Toolkits, Libraries, Frameworks, etc.  

Support for SHA-2 was introduced in OpenSSL 0.9.8, but is not enabled by default with SSL_library_init(). In 0.9.8, SHA-2 hash functions must be called specifically or by using OpenSSL_add_all_algorithms() which may not be desired. OpenSSL 0.9.8o enables the SHA-2 hash algorithms in the default configuration.

Database Support  

* The pgcrypto module for PostgreSQL introduced support for the SHA-2 family of hash algorithms with the 8.1 release but only for the standalone module. 8.2 incorporated the SHA-2 functions of the pgcrypto module into PostgreSQL core allowing these hashes to be available to PostgreSQL even if the installed version of OpenSSL does not support it.

Detailed Operating System Support  

Notes on «Partial» compatibility:
* S/MIME:

• Outlook on Windows XP SP3 can utilize certificates signed with SHA-256 but cannot validate an e-mail signed using the SHA-256 hashing algorithm.
• By default Outlook signs with SHA1 even if a SHA2 cert is in use though this behavior can be changed if desired.

** Code Signing:

• Code can be signed with a SHA2 cert on any of the systems listed as having partial or full compatibility without issue.
• There is an incompatibility with SHA2 signed kernel drivers on the partially compatible platforms. Kernel drivers signed with SHA2 certs will not install on systems listed as having «Partial» compatibility.

E-Mail Clients

The signature hash algorithm on the certificate itself is independent of the signature hash placed on an e-mail. For example, Outlook 2003 on XP SP3 can utilize a certificate signed with SHA-256 to sign an encrypt e-mails. But the signature on the e-mail will be limited to SHA1.

Set Outlook Hash Algorithm to SHA-1

Outlook 2003: Tools > Options > Settings > Security > Settings > Hash Algorithm > SHA1

Outlook 2007, 2010, 2013: File > Options > Trust Center > Trust Center Settings > E-Mail Security > Settings > Hash Algorithm > SHA1

Document Signing

Windows Code Signing  

  SafeNet iKey / eToken Compatibility

Mainframe 

Citrix Support

Sources:

[1] SHA2 and Windows.
[2] Common questions about SHA2 and Windows.
[3] OpenSSL 0.9.8 Branch Release notes
[4] Bug 222179 — User preferences should control ciphers used when sending encrypted S/MIME messages
[5] iKey 4000 Specifications
[6] eToken 5100 Specifications
[7] Verified In-House
[8] IBM Notes SHA2 Support
[9] IBM Domino Planned SHA-2 Support
[10] IBM HTTP Server
[11] IBM z/OS
[12] GnuTLS
[13] .NET Security Blog
[14] Security Advisory 2949927 (SHA-2 Hash Support for Kernel Drivers — Currently Retracted)
[15] SHA-2 Signed Executables Windows Vista & Server 2008
[16] VSTO Runtime Update to Address “Unknown Publisher” for SHA256 Certificates
[17] Digital Certificate Requirements (Technet)
[18] Mozilla NSS 3.8 Release Notes
[19] Java 1.4.2 Release Notes
[20] Availability of SHA-2 Code Signing Support for Windows 7 and Windows Server 2008 R2
[21] Add recognition of SHA-2 hashes when verifying S/MIME messages
[22] Thunderbird 38 Release Notes
[23] MYSQL 5.5 Release Notes
[24] PostgreSQL 8.1 Release Notes
[25] PostgreSQL 8.2 Release Notes
[26] PM62842: Web Services Security Runtime Update to Support SHA-2 Signature Algorithms
[27] Oracle Weblogic — Configuring SSL
[28] Certificate Requirements for Federation Servers
[29] Release Notes for the Cisco ASA 5500
[30] App Transport Security Technot

Hi all,

If you try to use any SHA-2 algorithm (SHA-256, SHA-384 and SHA-512) onWindows XP, you may getthe 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 CryptCreateHashwith 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 anyCSP 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.

Regards,

Alex (Alejandro Campos Magencio)