Runtime: Cannot import specified RSA private key

Created on 22 Oct 2020 · 13Comments · Source: dotnet/runtime

Description

When I trying to import the RSA private key above, .Net raises a CryptographicException with Key is not a valid public or private key..

I've tried with ImportFromPem and ImportRSAPrivateKey.

System.Security.Cryptography.CryptographicException: Key is not a valid public or private key.

System.Security.Cryptography.CryptographicException
Key is not a valid public or private key.
   at System.Security.Cryptography.KeyBlobHelpers.ExportKeyParameter(BigInteger value, Int32 length)
   at System.Security.Cryptography.RSAKeyFormatHelper.FromPkcs1PrivateKey(ReadOnlyMemory`1 keyData, AlgorithmIdentifierAsn& algId, RSAParameters& ret)
   at System.Security.Cryptography.RSA.ImportRSAPrivateKey(ReadOnlySpan`1 source, Int32& bytesRead)

Configuration

.Net 5.0 RC2 x64 on macOS 10.15

Regression?

I don't know.

Other information

This private key is from Signing HTTP Messages Draft Appendix A.1 and works well with openssl cli.

$ openssl rsa -in rsa.key -text -noout
Private-Key: (2048 bit)
modulus:
    00:84:02:98:76:da:1e:a3:2f:33:70:07:11:f3:be:
    0b:f1:c9:d9:c4:ac:c0:1b:07:7b:bf:7e:80:3e:9e:
    cf:bf:a4:36:8d:db:0f:05:1a:f0:58:40:67:7b:3e:
    9d:d1:40:ca:0f:01:9b:73:a9:f1:7c:45:c0:cb:99:
    9b:86:06:a3:ce:bc:37:30:e1:2d:f2:e0:39:b7:14:
    8a:a1:b0:69:28:37:81:2c:eb:1d:24:a1:6a:30:69:
    97:09:0b:c4:1b:b6:1e:99:cc:43:4d:13:f1:02:57:
    88:02:06:18:46:34:d2:77:f4:01:c1:55:bd:3b:03:
    45:85:e9:2b:a3:74:6d:96:29:d5:d1:ae:f9:8d:f6:
    60:92:77:bf:62:29:2d:4a:f2:c6:df:89:70:db:3a:
    97:04:34:c2:e4:d1:d1:39:4a:86:4e:53:0b:e0:f9:
    4d:65:2e:51:8b:65:38:68:23:71:da:b5:0f:45:c2:
    88:94:4d:0f:b8:ac:48:e1:3f:87:21:a1:69:bf:cf:
    ab:75:5e:9e:52:03:ab:07:6c:5e:23:57:52:14:59:
    ff:9e:7b:f9:3a:86:49:10:80:7e:56:6b:8a:9f:70:
    c2:51:c0:99:48:59:50:3d:25:d2:7c:10:e2:50:68:
    70:3b:0e:fa:5a:e4:92:b1:fd:43:e1:bf:ef:2e:82:
    75:d3
publicExponent: 65537 (0x10001)
privateExponent:
    6f:c9:66:e4:96:76:85:47:6e:2e:7a:be:38:02:82:
    48:e0:de:59:0e:d4:aa:ce:de:7a:dd:9b:a9:eb:80:
    0f:4f:f6:a6:8f:8f:1b:8a:a1:66:8a:3b:57:01:42:
    51:35:a5:25:a9:fd:c2:a7:71:88:03:e5:6c:44:0a:
    90:27:45:45:c6:da:91:b8:cd:d9:33:09:8c:c0:87:
    58:be:73:7e:0b:ea:86:68:1e:c8:ab:2b:aa:0d:70:
    49:c7:bd:ec:9d:7f:32:4b:e7:dd:f8:7a:09:ba:a7:
    c0:d6:fa:6d:51:43:bd:32:52:de:2e:45:cd:18:4a:
    8a:fe:ab:52:c6:26:f1:90:1d:17:85:d1:69:89:05:
    91:eb:87:3e:5e:eb:73:ea:ee:51:34:80:8c:2e:06:
    a2:fc:48:c6:80:c9:15:ed:2b:e2:46:c5:9a:48:99:
    3a:be:34:7b:c4:59:60:ae:d3:d4:82:ab:4a:fc:df:
    c7:1e:40:8e:79:4a:fc:e6:4e:4c:2a:b4:2f:bc:01:
    3d:b3:16:f8:8c:66:42:91:42:8e:92:3e:ca:ea:22:
    dc:59:59:1b:72:da:2c:da:c1:31:74:05:fe:52:d9:
    50:31:ec:ef:ba:b7:7c:01:b1:0d:6c:2e:9b:68:4a:
    05:f7:41:b9:44:2d:8e:5a:b0:8d:09:60:5c:fb:2c:
    91
prime1:
    00:b2:a7:94:26:6a:97:13:72:cf:f2:d6:28:22:33:
    08:00:a8:93:9b:da:3a:a6:c3:e5:73:c0:ab:2c:8f:
    42:1f:45:1b:b9:a0:36:24:23:8c:70:23:6a:f1:2c:
    98:6d:3a:a0:9d:69:41:f5:97:dc:02:6f:dc:16:90:
    3c:b5:87:22:f6:6e:6f:60:af:07:37:14:2b:fb:c1:
    52:dd:0a:3c:37:d4:49:f1:dd:14:e4:2b:30:0f:33:
    18:7d:18:21:01:f5:06:c2:69:56:8f:98:69:d6:94:
    33:02:e8:70:6c:e5:c5:b7:12:87:56:c3:0f:87:3d:
    48:06:d1:7d:63:c8:ef:82:a8:18:1c:b6:e6:ca:2b:
    b5:9b
prime2:
    00:bd:29:60:5d:06:ef:1f:35:a6:b9:40:45:44:70:
    1e:8d:18:7f:9d:a4:13:0d:5d:c6:9c:7e:25:71:11:
    ee:14:11:59:09:22:e7:f3:6c:50:4b:6f:fb:c4:53:
    aa:7d:a6:ea:ab:5e:e4:35:cb:ca:7f:37:6f:5a:91:
    b1:c4:9d:9c:20:b0:2a:d2:96:52:e8:39:ab:66:5b:
    c1:53:82:24:2b:66:47:09:a7:3f:5d:f5:95:64:58:
    7e:3e:bb:07:fc:49:d5:90:3a:5f:71:84:7f:8b:0d:
    45:e3:40:b5:ab:9c:3c:47:a5:81:1d:a7:b0:dd:20:
    29
exponent1:
    6a:2a:1d:66:ca:d6:a6:2f:07:15:f6:5f:79:1b:3c:
    39:2f:f4:2f:9c:7a:58:19:77:63:d6:ed:a1:98:2c:
    21:ea:ee:73:db:99:f0:d5:d3:21:dc:5a:33:a1:5d:
    9f:23:44:c8:e6:00:d5:51:fd:e2:d0:d8:47:ec:44:
    b7:56:eb:d6:e7:7f:76:43:ec:94:b5:7f:01:a7:3b:
    77:b1:1a:61:ce:dc:76:46:fb:a0:2f:6d:ea:ca:61:
    56:0d:1d:a8:4d:14:4c:39:4e:c0:1c:41:60:cb:46:
    99:06:c9:b0:5c:c6:a6:68:f3:56:02:aa:5a:a2:77:
    07:de:3b:96:2d:94:ee:de:b7:1d:71:2f:2a:9a:d8:
    db
exponent2:
    6f:40:f3:a5:23:1b:e6:9e:36:75:c4:20:39:35:3c:
    32:be:12:e8:93:84:85:1a:ff:62:31:2b:32:4a:5a:
    5d:41:2a:bd:9d:e3:10:1f:47:46:67:11:8b:91:ad:
    b7:83:41:88:13:22:63:a5:7d:6e:bf:1a:e6:08:c4:
    a6:20:10:a0:85:1c:5a:89:01:30:06:23:11:eb:ab:
    53:c3:3a:24:b0:5d:dd:86:99:55:58:c8:49:a1:66:
    76:dc:a7:c0:b1:68:43:10:a1:eb:f1:02:d6:b4:b2:
    c3:0a:df:0e:94:b0:3b:6f:52:f6:2f:17:6d:a6:a9
coefficient:
    3e:46:c0:44:b3:b0:53:f2:dc:66:b4:32:f6:69:9f:
    70:fa:10:94:0b:82:c9:eb:b5:43:d9:c7:ec:f6:12:
    9d:b1:d3:17:39:a2:b9:de:07:97:c6:c8:5d:4f:5a:
    d3:fe:7c:6e:50:e8:3a:5d:cf:72:d1:7e:6f:8a:c0:
    10:96:14:a4:23:83:bb:93:c5:c8:de:ae:10:56:11:
    83:e6:10:c2:98:c1:32:45:e4:f0:46:f7:f7:5d:bc:
    72:d0:11:07:8d:0b:c7:c7:1a:0e:14:5d:4f:26:84:
    79:d2:06:dd:c4:03:5d:2a:40:97:d1:0e:cd:79:33:
    7f:1e:1b:67:18:c0:1d:4f:66:90:c7:49:c0:e7:0c:
    0d

area-System.Security customer assistance

Source

kinosang

Most helpful comment

Author said they don't recall where the test keys came from, and in the process of asking, it appears I signed myself up for submitting changes with a new key.

vcsjones on 22 Oct 2020

😄2

All 13 comments

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @jeffhandley
See info in area-owners.md if you want to be subscribed.

msftbot[bot] on 22 Oct 2020

Thanks, I can reproduce it. I'll take a look.

vcsjones on 22 Oct 2020

P is too big (136 bytes, 1088 bits) compared to Q (120 bytes, 960). It means that the CAPI-required relationship of P/Q/DP/DQ/InverseQ being half the length of N (round up) doesn't work.

What produced this key? I can't recall ever seeing one where the bit-length of P and Q differed by 8 or more.

bartonjs on 22 Oct 2020

@bartonjs this is a 2048 bit key, but P and Q are not 1024 bits each. P is 1088 bits and Q is 960.

vcsjones on 22 Oct 2020

Aha, I even found the bounding recommendation in FIPS 186 that I remembered being there, but I gave up on finding a few paragraphs too early:

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf B.3.1:

In a footnote that spread from page 51 to 52:

In each case, len(p) = len(q) = nlen/2.

Or, really on pages 52-53 (PDF pages 61-62)

The primes p and q shall be selected with the following constraints:

(a) (p–1) and (q–1) shall be relatively prime to the public exponent e.

(b) The private prime factor p shall be selected randomly and shall satisfy sqrt(2)(2^((nlen / 2) – 1)) ≤p≤ (2^(nlen / 2) – 1), where nlen is the appropriate length for the desired security_strength.

(c) The private prime factor q shall be selected randomly and shall satisfy sqrt(2)(2^((nlen / 2) – 1)) ≤q≤ (2^(nlen / 2) – 1), where nlen is the appropriate length for the desired security_strength.

(d) |p – q| > 2(nlen / 2) – 100.

So a key generator that is FIPS 186 compliant generates both p and q as exactly the same bit size, namely precisely half the RSA keysize. Technically FIPS keys aren't a requirement unless you're doing FIPS-y things (though ANSI X9.31 tells the financial sector to do it, too), but it's still something that most key generators adhere to (in my experience).

bartonjs on 22 Oct 2020

What produced this key?

It's a sample key from the mentioned RFC draft.

This private key is from Signing HTTP Messages Draft Appendix A.1

vcsjones on 22 Oct 2020

D'oh, critical reading skills you let me down!

It's... probably... only CAPI that can't handle that key; so we could look into more flexible acceptance by types other than RSACryptoServiceProvider (ideally keeping the fake version of that type for Unix aligned with the real version for Windows). But just because CNG accepts a cbPrime1 and cbPrime2 in the importer doesn't really guarantee that everything goes swimmingly.

Since that spec is still under review, maybe it'd be reasonable to ask that their test key be a FIPS-compatible key.

Either way, since one of the sample signatures uses RSA-PSS it's not possible to reproduce the signatures, just verify them with the public key. The public key operations don't understand that the private key fails the factorization range requirement, so things should verify just fine.

bartonjs on 22 Oct 2020

👍1

maybe it'd be reasonable to ask that their test key be a FIPS-compatible key.

I reached out to an author, at least to understand where the key came from.

vcsjones on 22 Oct 2020

👍2

Author said they don't recall where the test keys came from, and in the process of asking, it appears I signed myself up for submitting changes with a new key.

vcsjones on 22 Oct 2020

😄2

I've updated links to the draft, from draft-richanna-http-message-signatures to draft-ietf-httpbis-message-signatures, cuz seems https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00 replaced the richanna edition (the newer one also include the FIPS non-compliant private key).

kinosang on 22 Oct 2020

Seems like you'll get a bigger diff out of it than I did with https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-update-alg-id-protect-01. My only contribution (that I know of) to-date to an RFC (https://tools.ietf.org/html/rfc8933#section-3.5)

(Sure, only Russ can really attest that those were mostly my words, but I know where they came from :smile:)

bartonjs on 22 Oct 2020

Regarding future keys...

It's... probably... only CAPI that can't handle that key

At the very least if I recall correctly P and Q in nbits must be a multiple of 64 for efficient CRT implementation. I seem to recall that some software rejecting keys with without that requirement since they didn't bother with not handling that case.

so we could look into more flexible acceptance by types other than RSACryptoServiceProvider

I checked macOS and CNG and they seem willing to accept RSA keys like this.

vcsjones on 22 Oct 2020

At the very least if I recall correctly P and Q in nbits must be a multiple of 64 for efficient CRT implementation.

I think we have an RSA-1032 import and use test, and that's not mod-64 so half it can't be mod-64. (It means P and Q are both only nybble-full, at 64.5 bytes each)

Mod-64 might make for an even more efficient model, but it's certainly not enforced by any of our 4 providers. :smile:

bartonjs on 23 Oct 2020

Was this page helpful?

0 / 5 - 0 ratings