This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.

[ktfollett]

Just started getting this exception at the end of December 2023. Thanks.

Exception Type: System.Reflection.TargetInvocationException Message: Exception has been thrown by the target of an invocation. Source: mscorlib Stack Trace: at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Security.Cryptography.CryptoConfig.CreateFromName(String name, Object[] args) at System.Security.Cryptography.Aes.Create(String algorithmName) at UglyToad.PdfPig.Encryption.EncryptionHandler.CalculateKeyRevisions5And6(Byte[] password, EncryptionDictionary encryptionDictionary, Boolean isUserPassword) at UglyToad.PdfPig.Encryption.EncryptionHandler..ctor(EncryptionDictionary encryptionDictionary, TrailerDictionary trailerDictionary, IReadOnlyList`1 passwords) at UglyToad.PdfPig.Parser.PdfDocumentFactory.OpenDocument(IInputBytes inputBytes, ISeekableTokenScanner scanner, InternalParsingOptions parsingOptions) at UglyToad.PdfPig.Parser.PdfDocumentFactory.Open(String filename, ParsingOptions options) at FUnction(String fileName, Boolean isPII, Boolean deleteFileWhenDone) Inner Exception: Date/Time: 01/02/2024 11:12:07.571 Exception Type: System.InvalidOperationException Message: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms. Source: System.Core Stack Trace: at System.Security.Cryptography.AesManaged..ctor()

[BhaaLseN]

You're probably running on a FIPS-enabled system in a .NET Framework project. In .NET Framework, they unfortunately made the assumption that any cryptographic primitive is used for a secure cryptographic operation, and thus must follow the NIST guidelines (or throw to prevent their use in potentially unsafe environments.)

.NET Core removed this requirement, since the only application that can determine if it is a secure cryptographic operation is the one using them.

You might wanna look into the <enforceFIPSPolicy> Element of the App.config file.

Specifically, you can place this snippet in your own applications App.config file to disable the FIPS enforcement and allow the use of those algorithms (which are used by PDF as per specification to generate unique identifiers and content hashes; none of which are classed as "secure cryptographic use" as far as I understood it):

<configuration>  
    <runtime>  
        <enforceFIPSPolicy enabled="false"/>  
    </runtime>  
</configuration> 

Because this is part of the .NET Framework runtime (as well as part of the PDF specification,) theres only so much PdfPig can do against this. The only way to get around this would be reimplementing those algorithms instead of using the ones provided by the framework; but that seems like a huge amount of work for very little gain.

[Numpsy]

The only way to get around this would be reimplementing those algorithms instead of using the ones provided by the framework; but that seems like a huge amount of work for very little gain

What's actually the reasoning for the code at https://github.com/UglyToad/PdfPig/blob/4537ec3f02c9f1f12e17e3a2e03f411c41d027de/src/UglyToad.PdfPig/Encryption/EncryptionHandler.cs#L691 to be explicitly requesting the managed implementation of AES? (just from memory, I think that the pure-managed implementation of AES isn't FIPS compliant, whereas the native/CNG implementation is).

Also maybe refs #664, where asking for an implementation by string name causes warnings about the linker trimming machinery potentially removing the code.

[BhaaLseN]

Thats true for AES, but PDF also uses/suggests other algorithms such as MD5 for file identifiers (see PDF 1.7, section 10.3) which are most certainly not FIPS compliant, no matter which implementation is used.

(But also, yes, there are better/recommended ways of creating those today.)

[Numpsy]

FIPS mode is always a pain :-(

This also reminds me - There were some changes to the defaut behavior in .NET Framework 4.8 as well - https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/retargeting/4.8.x#managed-cryptography-classes-do-not-throw-a-cryptographyexception-in-fips-mode

[Numpsy]

@ktfollett Are you able to test this with the latest nightly build to see if it's improved things?

[ktfollett]

We were just able to test today, and Thanks so Much, this fixed our issue.

[BobLd]

Closing as fixed with #747