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

Reply via email to