SOLVED

Using get-filehash on fips enabled system

Copper Contributor

Using get-FileHash on a FIPS enabled system results in:

 

ERROR:

 

Exception calling "Create" with "1" argument(s): "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms."

At

C:\windows\system32\windowspowershell\v1.0\Modules\Microsoft.PowerShell.Utility\Microsoft.PowerShell.Utility.psm1:26

char:9

+         $hasher = [System.Security.Cryptography.HashAlgorithm]::Create($Algorith ...

+        

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ ~~

    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

    + FullyQualifiedErrorId : InvalidOperationException

 

 

Is there a method to compute a filehash, or is their a Get-FileHash algorithm that will operate with FIPS mode enabled?

 

I cannot disable FIPS, but I need to calculate a SHA256 or SHA512 hash for a file in PowerShell.

 

4 Replies

@cc1024 

 

Being Australian, I'm unfamiliar with FIPS, but it may be worth quickly trying one of the newer SHA algorithms, such as SHA256 or above.

 

Get-FileHash -Algorithm SHA384 -Path somefilepath

 

Cheers,

Lain

Lain

Thank you for the response. Pretty much all of the algorithms are failing. I would understand MD5 being a problem. We are looking at the system to see if it is having other issues.

Thanks!
best response confirmed by cc1024 (Copper Contributor)
Solution

@cc1024 

 

I knocked up a test Windows Server 2022 Server Core guest and tested Get-FileHash with and without FIPS enabled.

 

As you'd expect, with FIPS disabled all the available hash algorithms worked.

 

With FIPS enabled, the only two algorithms that failed were MD5 and RIPEMD160. The remainder worked just fine.

 

Testing just that one setting (enabling FIPS) is hardly rigorous but it does seem to suggest that additional configuration is causing the issue, not FIPS on its own.

 

You might also want to check out if any customisation of the TLS ciphers has been done via group policy and/or the registry as outlined below, as this can also impact hashing.

 

I know I've done this in the past as a means to only allowing algorithms that support Perfect Forward Secrecy, so while it's only an educated guess at best, it may be worth checking.

 

Manage Transport Layer Security (TLS) | Microsoft Docs

Restrict cryptographic algorithms and protocols - Windows Server | Microsoft Docs

Transport Layer Security (TLS) registry settings | Microsoft Docs

 

I'm not sure if you have access to the following commandlet, but if you do, it's a quick way to get an idea on which suites are currently enabled, and while I'm not sure if it enumerates them in order, possibly which is providing the first relevant hash match. My guess is that a disallowed suite is providing the first match.

 

 

(Get-TlsCipherSuite) | ft -AutoSize Name, Exchange, MaximumExchangELength, Hash, HashLength

 

 

Cheers,

Lain

Lain,

Awesome! Thank you. On most servers we have, I see the same result with MD5, and RIPEMD160.
The system I need my PowerShell to run on, however, fails on the others, so I will check out the cipher suite as you recommend. I am suspecting that the system may have gotten more of a lock down than required.

I appreciate you taking the extra time to check this out and for sending the links to the articles.

Thank you!
1 best response

Accepted Solutions
best response confirmed by cc1024 (Copper Contributor)
Solution

@cc1024 

 

I knocked up a test Windows Server 2022 Server Core guest and tested Get-FileHash with and without FIPS enabled.

 

As you'd expect, with FIPS disabled all the available hash algorithms worked.

 

With FIPS enabled, the only two algorithms that failed were MD5 and RIPEMD160. The remainder worked just fine.

 

Testing just that one setting (enabling FIPS) is hardly rigorous but it does seem to suggest that additional configuration is causing the issue, not FIPS on its own.

 

You might also want to check out if any customisation of the TLS ciphers has been done via group policy and/or the registry as outlined below, as this can also impact hashing.

 

I know I've done this in the past as a means to only allowing algorithms that support Perfect Forward Secrecy, so while it's only an educated guess at best, it may be worth checking.

 

Manage Transport Layer Security (TLS) | Microsoft Docs

Restrict cryptographic algorithms and protocols - Windows Server | Microsoft Docs

Transport Layer Security (TLS) registry settings | Microsoft Docs

 

I'm not sure if you have access to the following commandlet, but if you do, it's a quick way to get an idea on which suites are currently enabled, and while I'm not sure if it enumerates them in order, possibly which is providing the first relevant hash match. My guess is that a disallowed suite is providing the first match.

 

 

(Get-TlsCipherSuite) | ft -AutoSize Name, Exchange, MaximumExchangELength, Hash, HashLength

 

 

Cheers,

Lain

View solution in original post