ECDsa.Create(ECParameters) behavior is not consistent across platforms with a public/private key mismatch

[bartonjs]

Create an ECParameters for secp256r1 (ECCurve.NamedCurves.nistP256) with

D = 9F9BD156374FB78F3D69EFF10DEF8C296EC4F03EACA42F4257130D0CE9316FCD,
Q.X = 6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
Q.Y = 4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5

(That X/Y pair is for the curve point G, not the key point Q)

On Linux (via OpenSSL)

Unhandled Exception: Interop+Crypto+OpenSslCryptographicException: error:100B107B:elliptic curve routines:EC_KEY_check_key:invalid private key
at System.Security.Cryptography.ECOpenSsl.ImportParameters(ECParameters parameters)

On Windows, success (the Q value seems to be rederived from D).

Since it's probably hard to make Linux and macOS coerce Q, it's probably more practical to make Windows throw (theoretical process: NCryptImportKey, then NCryptExportKey and compare the target Q value, then dispose the new key handle and throw before replacing the existing key handle).

[vcsjones]

@bartonjs I can pick this up if you want; or at least noodle around with some ideas. I have some spare cycles to pick up 3.0 bugs. Let me know if you think there is something else that would be a better use of my time.

[bartonjs]

@vcsjones Any progress / are you still looking at this one? https://github.com/dotnet/corefx/issues/37595 seems pretty similar.

[vcsjones]

@bartonjs I haven't made any significant progress. I was meant to get back in the swing of things but only a few hours ago have I managed to figure out why I could not build CoreFX for the past two weeks due to dotnet/corefx#37907 😅

I'll be looking at this very near term.

[bartonjs]

Given that this isn't new in 3.0 I'm moving to Future (PRs while 3.0 is still open are still welcome).

[vcsjones]

and compare the target Q value

Hm. One thing that makes this interesting is insignificant zeros. For example, these parameters work fine with OpenSSL:

var dStr = "000087E2DD50E8204FB80A5FBFC041859CCE0730ACCE1A828918E01461E468DDAD87";
var qYStr = "000038C4CDC289845DF49CDA665A64339D57FF900E231BD57082021493ECC21B325B";
var qXStr = "0000253DA14B518037CF07D578614E46CA8EA071FB9B4374EF05AD45418A81675828";

However when exported again, the insignificant zeros are not included. So if we do a import / export / test in Windows and compare byte-for-byte, we end up with a scenario where Windows does not tolerate insignificant zeros, but OpenSSL does, and the behavior remains inconsistent.

You can't blindly pull off zeros, either, since the curve points may legitimately need the octets to be the appropriate size. For example:

D: CFB75FF7B9BB2F53D4A50703285C3DE78C24F1E21486DE59F83E27C317BB4EF1
X: 000026B190372A1899972893526864834DE5ECB17BE8A852424A7B99C95A86C9
Y: 63DFF42F953F6F6EE94CF674C01D537F82C0979B878588A7F28B5CD232283A30

I think then, the appropriate way to handle this then is, when exporting for comparison, we assume that the import validated the points are on the curve. When comparing, compare the octets from the end using the smallest number of octets. For the one that is bigger, if there is, assert that the remainder are zeros.

For example, given:

"000087E2DD50E8204FB80A5FBFC041859CCE0730ACCE1A828918E01461E468DDAD87"

is exported as

"87E2DD50E8204FB80A5FBFC041859CCE0730ACCE1A828918E01461E468DDAD87"

Compare from the end of the byte array (since big endian) using the number of bytes that was exported (32) and verify the rest are zeros.

[bartonjs]

Yeah, X.Slice(X.Length - exportedX.Length).SequenceEqual(exportedX) seems like a reasonable comparison.

[bartonjs]

(Er, and that any remaining bytes of X were zero)

[vcsjones]

For the sake of completeness, if your D, QY and QX all have leading zeros, you can import them still with OpenSSL (haven't checked Windows, yet). e.g. these work:

var dStr = "DFEE4545BF488935EEC834DEBB1DD256CD87D8C7894EFC50E5722627169941";
var qYStr = "B8A6F5DC31A1D416CEBC694307FD99BE4E1EEC623A332A71E03A827DF58554";
var qXStr = "618DB65F240DBA24D745959BF4CE260E0F946856A4DF2450915416EBCA7FBA";

These are 31-byte values for a p256 curve.

So it's possible that the byte values imported are smaller than the ones that get exported.

[vcsjones]

Heh, well, macOS will not import 31-byte points for p256, nor will it tolerate "zero padded" values. It is pickier.

[bartonjs]

The most consistent behavior, then, would be to determine the correct parameter size post-import and reject it if it was non-canonical. (Alternatively, on macOS create a new key using the the curve identifier, memoize the resulting size (okay, yeah, currently there's only the 3 so they could be hard coded), and fix up the parameters to be canonical.)