UserPassword stopped working in 6.x series in Edge

[PavlinII]

PdfSharp 6.x series have a bug when setting UserPassword property. The document cannot be opened with Edge (🤦).

Working versions

• 1.50.5147, targeting net48

Broken versions used for reproducing

• 6.0.0, targetting net8.0
• 6.1.1, targetting net8.0 and net48
• 6.2.0-preview-3, targetting net8.0

The issue was reported to us by several independent customers.

Expected Behavior

Document can be opened in Edge with correct password.

Actual Behavior

Document does not open due to some password issue.

Steps to Reproduce the Behavior

1. Create blank page PDF

Dim PDF As New PdfSharp.Pdf.PdfDocument
PDF.AddPage()
PDF.SecuritySettings.UserPassword = "1234"
PDF.Save("D:\_Temp\File.pdf")

or C# version from #253

var PDF = new PdfSharp.Pdf.PdfDocument();
PDF.AddPage();
PDF.SecuritySettings.UserPassword = "1234";
var filename = "File.pdf";
PDF.Save(filename);

2. Open it with Edge

Or send it to some unfortuante user that's still using Edge 🤦

Side notes

It works in Acrobat and Chrome.

Tested with Edge 135.0.3179.98 64bit
Tested with Edge 136.0.3240.50 64bit

This doesn't seem to be related to #253, as that one was TFM-specific. My wild guess is that some additional metadata is expected by Edge that was present in 1.50.5147 and removed in the migration.

[Greybird]

We also had the issue, and were able to track it down to the edge pdf viewer specifically.
If using edge://flags, the integrated pdf viewer is disabled, then the PDF can be opened. If it is enabled then the file cannot be opened.

Putting back the encryption to /V 2 / R 3 from the default is also working.

[ThomasHoevel]

My wild guess is that some additional metadata is expected by Edge that was present in 1.50.5147 and removed in the migration.

Or maybe the difference is a different default encryption setting.

We cannot debug Edge to find what their problem is.
Did you report this to Microsoft?

[PavlinII]

Did you report this to Microsoft?

No, I have no idea how to do that.

[PavlinII]

As @Greybird mentioned above, disabling edge://flags/#edge-new-pdf-viewer works around the problem. Unfortunatelly, it's not acceptable solution for general nontechnical population.

This workaround also seems to work:

PDF.SecurityHandler.SetEncryptionToV2With128Bits()

[atell0143]

I also had the issue.

The likely cause is that the /Length entry is missing from the encryption dictionary when encrypting with /V 4.
In most cases, this value is effectively superseded by the crypt filter settings, so it should not be necessary in practice. However, some environments treat its absence as an error; for example, inspecting such a PDF with qpdf --check detect an "unsupported key length" error.
Whether this is the correct solution or not, I confirmed that setting /Length to 128 resolves the issue in both Edge and qpdf.

[martinossendorf]

We checked this issue, and think the generated PDFs are correct (see below). We could not reproduce the issue with Edge. We successfully opened a file created with the posted test code and PDFsharp 6.2.0-preview-3 targeting net8.0 with Edge 143.0.3650.66. We assume that the issue is fixed in Edge meanwhile. We did not test it with qpdf. If the error still occurs there, please contact the qpdf developers. Like @PavlinII mentioned, you could use /V 2 as a workaround, if you depend on another program to open your files, that has issues with the newer encryption versions.

Why is the /Length key missing sometimes?
Due to the PDF reference 2.0, the /Length key is optional and deprecated in PDF 2.0. It only applies to /V 2 and /V 3. /V 3 uses an unpublished algorithm and shall not appear in a conforming PDF file.
So, /V 2 is the only encryption version, the /Length key shall be used for.
In PDFsharp 1.5 only encryption /V 2 with a 40-bit key length was implemented, so the /Length key was always present when writing an encrypted file.
In PDFsharp 6.x encryption /V 1, /V 2, /V 4, and /V 5 are implemented, while /V 4 using AES with a 128-bit key length is the default. For /V 1 there is no /Length key, for /V 4 and /V 5 the /Length key is set at the crypt filter instead.

Please contact us, if you think we're wrong.

[Greybird]

@martinossendorf , can you clarify if you tested using both settings of Edge with regards to the pdf viewer ?

[atell0143]

In my environment, files created with PDFsharp 6.2.3 targeting net8.0 still cannot be opened with Edge 143.0.3650.75.
Even with the latest Edge, it seems to work in some environments but not others. The common factor across all environments is that enabling edge://flags/#edge-new-pdf-viewer reproduces the issue, while disabling it allows the files to open successfully.

I agree that the generated files have no issues when compared against the PDF reference.

[Greybird]

@martinossendorf , @atell0143 , just confirmed it on my side also with version 143.0.3650.75 also, with edge://flags/#edge-new-pdf-viewer set to Enabled.

Enabled will be the default experience for all users starting June 2026, and, since October 2025 and version 141 of Edge (IIUC), the Default settings can be equivalent to Enabled, so the issue will get worse I would say (source: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel#version-1410353757-october-2-2025)

[martinossendorf]

The new PDF viewer was obviously not enabled by default in my Edge 143. I enabled it and could now reproduce the issue. We'll re-investigate.