Thanks Dave. Where do you get the cert file to use as input? On Mar 22, 2014 9:37 AM, "Dave Thompson" <dthomp...@prinpay.com> wrote:
> 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 <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 <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 <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 >
