Skip to content

[release/11.0] X25519: Handle zero peer keys on downlevel Windows platforms - #134607

Open
github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-134535-to-release/11.0
Open

github-actions[bot] wants to merge 1 commit into
release/11.0from
backport/pr-134535-to-release/11.0

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor

Backport of #134535 to release/11.0

/cc @vcsjones

Customer Impact

  • Customer reported
  • Found internally

The X25519DiffieHellman class that was introduced in .NET 11 did not handle certain invalid public keys in an expected manner. These public keys should allow being imported, but should reject being used while deriving secret agreements.

On older, but supported, builds of Windows 10, the Windows implementation would either reject too early, or too late, making its behavior inconsistent with other platforms. This was uncovered when Hpke had test cases added that exercised error paths.

Regression

  • Yes
  • No

Testing

New test were added.

Risk

Low. Small, well understood, and isolated change to X25519DiffieHellman's Windows implementation.

An all-zero peer (public) key should always produce a zero shared secret, which should get rejected during key agreement.

Windows normally rejects this during importation time, but that is not enabled because Windows would also eagerly reject off-twist public keys which should work. With this change, when a "zero" public key is imported (either by naturally being zero or reduced to zero) we skip
importing it into bcrypt and retain "This was a zero key". During derivation we throw since that would produce a zero shared secret. This
keeps Windows consistent with other platforms, where import is not the protected path, but derivation is.

For X25519DHCng (ncrypt) its not possible to really gate this when the peer key is zero. However that responsibility falls to the person
creating the public key handle, and the handle is external in this case.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@azure-pipelines

Copy link
Copy Markdown
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

Copy link
Copy Markdown
Contributor

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

@bartonjs

Copy link
Copy Markdown
Member

/azp run runtime-coreclr libraries-jitstress

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-System.Security os-windows Servicing-consider Issue for next servicing release review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants