Forum Discussion

cc1024's avatar
cc1024
Copper Contributor
Apr 26, 2022
Solved

Using get-filehash on fips enabled system

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.

 

  • 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

4 Replies

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor

    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

    • cc1024's avatar
      cc1024
      Copper Contributor
      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!
      • LainRobertson's avatar
        LainRobertson
        Silver Contributor

        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

Resources