Note: a PKCS12 isn’t really a cert, despite many people including MS miscalling it so, partly because there isn’t a really good specific name –
credential comes comes close but has a range of related meanings. It is an (almost always) encrypted private key, an optionally encrypted matching cert, and optionally other CA (chain and root) certs. In my case, I create my fake certs directly under a fake root and need no CA certs; you will rarely if ever see an entity cert directly under the root of a real/public/established CA. For this minimal case, creating a PKCS12 is just openssl pkcs12 –in certfile.pem –inkey privkey.pem –export >p12file or since I have Unixoid (mingw) tools on my system cat privkey.pem certfile.pem | openssl pkcs12 –export >p12file www.openssl.org/docs/apps/pkcs12.html for more options. I load it from Explorer. Just name the file something.p12 and doubleclick (or Start), which runs rundll32 with cryptext.dll,CryptExtAddPFX (filepath) then go through the dialogs. I have no idea what API that uses, but I’d guess it’s whatever MS recommended at the time it was released. FWIW I dug out my old XPSP3 box (not quite dead yet) and that does fail the import with “The private key … is not supported by the targeted [CSP]”. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of andrewarn...@gmail.com Sent: Friday, March 21, 2014 21:03 To: openssl-users@openssl.org Subject: *** Spam *** Re: When P is larger than Q I’d like to try the PKCS12 idea. Can you tell me how you put this private key in a PKCS12 cert so I can see if I can adapt that to get this working in my .NET app? I tried generating dozens of 512 bit keys in a row on iOS. Every time, the P was longer than the Q. It seems that iOS may be doing this intentionally. Sent from Surface Pro From: Andrew Arnott <mailto:andrewarn...@gmail.com> Sent: Friday, March 21, 2014 4:33 PM To: openssl-users@openssl.org Hi Dave, Thanks for your reply. I've attached a simple console app that attempts to import the key data into a .NET RSACryptoServiceProvider. Internally this class just sends it straight onto the Windows OS crypto library, which includes the checks that P and Q must have equal lengths. The code includes a ValidateParameters method that has the same checks that Windows internally uses to determine whether it is Bad Data or not. It would seem that your certificate test that you ran (and thank you very much for the time you took trying it out!) might have somehow bypassed the test of lengths. Whether that can somehow be leveraged in a .NET app and used for both encryption and authentication is (for me) the ultimate question. Sent from Surface Pro From: Dave Thompson <mailto:dthomp...@prinpay.com> Sent: Friday, March 21, 2014 3:37 PM To: openssl-users@openssl.org To be clear: it is conventional to generate P with a larger *value* than Q, AIR so that CRT qinv-modp works right. There are several ways to do this; openssl just generates two suitable primes and chooses the larger one as P. Your issue is that P has *more significant bits*, 257 instead of 256. I don’t think this violates any standard and it works fine on my Windows (which is 7). I took your privatekey, which is indeed PKCS#1, generated a (fake) cert, put them in a PKCS12, which Windows imported okay and IE(9) was then able to use to authenticate to my test server (which trusts the fake cert). Where are you seeing the “Bad Data”? AIVR there is an attack on RSA if the two primes are *very* close (maybe something like 256-bit primes within 2^64 or so). It’s conceivable that iOS went *way* overboard in avoiding that weakness. AFAICS openssl doesn’t even check, apparently relying on the fact the primes chosen independently in 2^(n-1) to 2^n are overwhelming unlikely to be too close – probably less likely than your computer turning into cottage cheese during the key generation process. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Andrew Arnott Sent: Friday, March 21, 2014 01:32 To: openssl-users@openssl.org Subject: *** Spam *** When P is larger than Q I've noticed that iOS RSA keys (which I believe are generated using openssl underneath it all) are created with P larger than Q, which is posing a problem for me. When I export the 512-bit private key from iOS, I get a PKCS#1 formatted key. When I decode that into RSAParameters, I see that P and Q are of unequal size (Q is 32 bytes and P is 33). This makes Windows reject it as Bad Data, since it is expecting both P and Q to be exactly half the length of the modulus. Note that the extra byte is not a leading (or trailing) zero. The first byte is a 1. And that 1 is significant. I verified that p*q=mod when p includes the leading 1. So I’m a little dumbfounded that iOS would produce a key where p is longer than q, particularly since Windows seems to disallow that. Given this, I don’t know how to pass a private key from iOS to Windows. I'm wondering whether P is supposed to be larger than Q, if there is something I can do to suppress that when generating keys, or if there's anything I can do to coerce them to be the same length later. I tried just padding Q with a leading 0, and then padding the modulus as well since it's supposed to be twice the length of P and Q, but that led to encryption that had leading zeros in the ciphertext and decryption failed. Thanks. Any ideas? One specific 512-bit key I generated as part of a test is below, with all the variables I decoded from it, in big endian. * Raw private key data exported from iOS (believed to be PKCS#1 format): MIIBOgIBAAJBALx0Z0O1n/2E+ Boyt7UEIQD62y8MQQPILJC2AguHvPfo8E5ScBBPa8dMCHVRCcKJJ868F JdebracYthqCHn19KMCAwEAAQJBAKAgsFXCD+2UfFOWYK44keqJPJBfcybJgcR8QoSVk6V40MkwgAm jVn4cumCLZgxwJ+O5fbS/xmzeRSBz8gdPfrECIQGbqLr8paSZLW80ixXQK9YCx76nkg4I2UdBq+h5taAwn QIgdTHt32eGkYjiVT81BnM6D9pmX508VulYsBalYtbmlj8CIEYX4dbZAYDPeqrwr8MlY6hPiIgR12/sRzTIZ6 opoeAFAiAtESA6UuNKv+rZgU7wxgrD4eaQSjTT7zPtsyeyVJWjnQIhAONhytT6rHH9n3nE4K7Xxz3DjYodX zzM6Bm2C1jiGrEM * Modulus: vHRnQ7Wf/YT4GjK3tQQhAPrbLwxBA8gskLYCC4e89+jwTlJwEE9rx0wIdVEJwoknzrwUl15utpxi2GoIefX0ow== Exponent: AQAB D: oCCwVcIP7ZR8U5ZgrjiR6ok8kF9zJsmBxHxChJWTpXjQyTCACaNWfhy6YItmDHAn47l9tL/GbN5FIHPyB09+sQ== P: AZuouvylpJktbzSLFdAr1gLHvqeSDgjZR0Gr6Hm1oDCd DP: Rhfh1tkBgM96qvCvwyVjqE+IiBHXb+xHNMhnqimh4AU= DQ: LREgOlLjSr/q2YFO8MYKw+HmkEo00+8z7bMnslSVo50= Q: dTHt32eGkYjiVT81BnM6D9pmX508VulYsBalYtbmlj8= InverseQ: 42HK1Pqscf2fecTgrtfHPcONih1fPMzoGbYLWOIasQw= -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre