.NET wraps the platform's cryptography — CNG on Windows, OpenSSL on Linux, Apple's libraries on macOS — behind one API: ECDsa, RSA, MLDsa, MLKem and friends. The check ran .NET 10.0.13 on Ubuntu 24.04, where the OpenSSL underneath is 3.0.13, and that version shapes several results.
The default signature encoding is the opposite of most server-side libraries. ECDsa.SignData returns the 64-byte IEEE P1363 r‖s and VerifyData expects it; DER requires DSASignatureFormat.Rfc3279DerSequence on both calls. That makes .NET match JWS and WebCrypto out of the box and mismatch OpenSSL, Java's SHA256withECDSA and Go's SignASN1. Every malformed or mismatched signature makes VerifyData return false, so a DER signature checked with the default format looks exactly like a forgery — the sample shows both outcomes, and the DER ⇄ raw converter shows which one you have.
On Linux, ECDSA covered P-256 to P-521, secp256k1 and the Brainpool r1 curves, all through OpenSSL. SignHash signs a digest you computed, nonces are random, s is not normalized and verification accepts high-S. There is no Ed25519 or Ed448 class in the base class library; EdDSA needs Bouncy Castle for .NET or another package.
MLKem, MLDsa, SlhDsa and CompositeMLDsa exist in .NET 10, but each reports IsSupported according to the platform. With OpenSSL 3.0.13 every one of them was false; OpenSSL added ML-KEM and ML-DSA in 3.5, so on Linux they need a distribution that ships it, and on Windows the corresponding CNG support. Code must check IsSupported rather than assume, and this page has not verified any platform where the answer is true.
Keys import from SPKI and PKCS#8 (PEM or DER, encrypted or not), SEC1 EC PRIVATE KEY and raw ECParameters coordinates; there is no SEC1-point or JWK import. Inspect PFX bundles with the PFX inspector.