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+2UfFOWYK44keqJPJBfcybJgcR8QoSVk6V40Mkwg Am jVn4cumCLZgxwJ+O5fbS/xmzeRSBz8gdPfrECIQGbqLr8paSZLW80ixXQK9YCx76nkg4I2UdBq+h 5taAwn QIgdTHt32eGkYjiVT81BnM6D9pmX508VulYsBalYtbmlj8CIEYX4dbZAYDPeqrwr8MlY6hPiIgR1 2/sRzTIZ6 opoeAFAiAtESA6UuNKv+rZgU7wxgrD4eaQSjTT7zPtsyeyVJWjnQIhAONhytT6rHH9n3nE4K7Xxz 3DjYodX zzM6Bm2C1jiGrEM * Modulus: vHRnQ7Wf/YT4GjK3tQQhAPrbLwxBA8gskLYCC4e89+jwTlJwEE9rx0wIdVEJwoknzrwUl15utpxi 2GoIefX0ow== Exponent: AQAB D: oCCwVcIP7ZR8U5ZgrjiR6ok8kF9zJsmBxHxChJWTpXjQyTCACaNWfhy6YItmDHAn47l9tL/GbN5F IHPyB09+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
