Improve PemEncoding.TryFind perf with degenerate inputs

[bartonjs]

Rather than seeking for the correct PostEB, just ask if the next hyphen is the PostEB. If not, we can bypass the IsValidBase64 checks.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

[Copilot]

🟡 Changes recommended

The new tests have an off-by-one Range expectation for Location, and both PemEncoding implementations have a boundary check that can incorrectly accept a single trailing non-whitespace character after the PostEB.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates PemEncoding.TryFind to short-circuit scanning for the post-encapsulation boundary by first locating the next '-' and only doing more expensive work if that position begins a valid PostEB, and adds regression tests targeting pathological inputs with many BEGIN markers.

Changes:

• Optimize PostEB discovery in PemEncoding.TryFindCore (both in-box and downlevel) to reduce work on degenerate inputs.
• Add a large “many begins, one end” regression test in both System.Security.Cryptography and Microsoft.Bcl.Cryptography test suites.

File summaries

File	Description
src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/PemEncoding.cs	Reworks the PostEB search logic to check the next hyphen and skip expensive base64 validation in common-degenerate cases.
src/libraries/System.Security.Cryptography/tests/PemEncodingFindTests.cs	Adds a stress/regression test exercising many BEGIN headers before a single valid PEM.
src/libraries/Microsoft.Bcl.Cryptography/src/System/Security/Cryptography/PemEncoding.cs	Mirrors the PostEB search optimization in the downlevel implementation.
src/libraries/Microsoft.Bcl.Cryptography/tests/PemEncodingFindTests.cs	Adds the corresponding downlevel regression test for the degenerate input scenario.

Review details

Suppressed comments (2)

src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/PemEncoding.cs:249

• Typo in comment: "alledged" should be "alleged".

 {
// No matches can occur before the alledged post-EB suffix,
// so jump ahead.

src/libraries/Microsoft.Bcl.Cryptography/src/System/Security/Cryptography/PemEncoding.cs:137

• The whitespace-after-PostEB check uses pemEndIndex < pemData.Length - 1, which skips validating the last character when there is exactly one trailing character after the PostEB. Use pemEndIndex < pemData.Length so a single trailing non-whitespace character is rejected consistently.

 // The PostEB must either end at the end of the string, or
// have at least one white space character after it.
if (pemEndIndex < pemData.Length - 1 &&
!IsWhiteSpaceCharacter(pemData[pemEndIndex]))
{

• Files reviewed: 4/4 changed files
• Comments generated: 6
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

It changes subtle PEM boundary-search behavior in security-sensitive parsing logic and should get a careful human validation pass over edge cases and perf claims.

Review details

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

src/libraries/Microsoft.Bcl.Cryptography/tests/PemEncodingFindTests.cs:473

• The loops that append repeated characters build a very large string (~4MB) one character/chunk at a time, which can make this unit test unnecessarily slow. StringBuilder has repeat-count overloads that avoid the per-iteration overhead while producing the same content.

This issue also appears on line 475 of the same file.

src/libraries/Microsoft.Bcl.Cryptography/tests/PemEncodingFindTests.cs:478

• Building the large base64 section via a loop of Append("AAAA") does ~1M iterations for a 4MB payload and can slow the test suite. Prefer the Append(char, int) overload to append the same number of 'A' characters in one call.

 for (int i = 0; i < div4; i++)
{
builder.Append("AAAA");
}

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[vcsjones]

Looks good with a non-blocking suggestion.

[Copilot]

🟢 Approval recommended

The updated search strategy appears behavior-preserving for valid PEM while addressing the degenerate-input scenario, and the PR adds targeted regression coverage for the new logic.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[bartonjs]

/ba-g #131990

[bartonjs]

/backport to release/11.0

[github-actions]

Started backporting to release/11.0 (link to workflow run)

[bartonjs]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)