1
$\begingroup$

my question is just for teaching/learning practice and I think it's not meaningful for the real world.

I've played with openssl a lot but from my understanding it's somehow not strict in the format of the input because it's capable of understanding different format or doing some operations not transparently to the user.

Getting to the question: is there way by using openssl to get just the private key from the key pair and from that private one to compute the public key? An example:

When I do openssl rsa -in private.key -pubout I know that openssl does not compute the public key from the private but it just extracts the information that is alredy stored in the keypair (private.key is indeed a store for the pair).

Also openssl pkey -in private.key -text claims to extract the private key but how I can be sure that it's not another keypair storage? Ideally I would use another software than openssl that IS stricter with the input it receives and feed it with the private key and that would complain if as input it's given the keypair.

It might be that the confusion I'm trying to clear comes from the fact that maybe I'm missing some details of the cryptography but I'd like to check that by playing with different softwares (i.e. encrypting data with one software and decrypting it with another), again a software that is strict about what it gets as input, in another terms not-user-friendly but learner-friendly :-)

For software I prefer to have something at hand and not to compile anything.

Thanks for reading till here :-)

Alex

Improve this question
$\endgroup$

3 Answers 3

Reset to default
0
$\begingroup$

OpenSSL supports several different formats for RSA private keys, but the actual key value in all is identical. All use ASN.1 and the differences are

  • whether the format handles RSA only (called "legacy" or "raw" PKCS#1) or can handle other algorithms (PKCS#8) which is usable somewhat more generally (still not very)

  • whether the key value is encrypted or not

  • whether the file contains the direct encoding of the ASN.1 data (called DER or sometimes binary) or a textual encoding more convenient for humans, and applications designed for human interaction with mostly text like email and WWW (called PEM or sometimes base64; PEM actually consists of base64 with "BEGIN" and "END" lines added, so the base64 is the part that usually interests people)

As suggested by @poncho's comment, the ASN.1 RSAPrivateKey is the optimized CRT form and already includes the two values needed for the public key (n and e); the -pubout option consists of reading the privatekey in (any) privatekey format and writing the publickey format with those two fields; no computation is needed. (Formally there are also multiple formats for publickey, but only two are used in practice: X.509 SPKI in DER or PEM.)

Except for encryption, converting between the other two options (legacy vs PKCS#8 and binary vs PEM) is simple and independent (or very nearly) of the actual key. Since all unencrypted forms are ASN.1, you can apply any ASN.1 dump or parse program (there are lots, including one in OpenSSL, but you apparently distrust OpenSSL) and compare the results to the published PKCS#1 and PKCS#8 standards, or their republications as RFCs 3447 and 5208. If you don't trust an ASN.1 program, you can look at the binary encoding (or the base64 converted to binary) with any hex dump or hex editor program and decode ASN.1 DER by hand, which is straightforward if a bit tedious, and the results of that to PKCS#1 or PKCS#8 as above.

Any other program you use which is "stricter" about its input could still use "another storage"; those concepts are completely independent. You can only write the code entirely yourself (and even then you could worry about the compiler tricking you!), examine the code yourself (OpenSSL is FOSS, but pretty big and complicated and much of it old with little or no comments), or trust somebody.

Finally for context, there is also a later and more popular standard PKCS#12 (based on Microsoft PFX) that handles privatekeys (in PKCS#8 multi-algorithm format) PLUS related certificates (in X.509 format, which is also multi-algorithm). OpenSSL supports converting privatekeys to and from PKCS#12, but does not use it as a "native" format.

Improve this answer
$\endgroup$
1
  • $\begingroup$ My mistrust comes from my not-enough-knowledge in cryptography since for me OpenSSL is a far from theory much like "private key never encrypts messages" because there is no reason in encrypting a message that everybody can decrypt. For beginners in cryptography it's perfectly fine to encrypt a message with a private key. Then this guy realizes that encrypting a message is ok for authentication but you double the data to be sent. Then hash comes into play and it's much shorter. I'm closing the gap between theory and real world so that everything (or almost) makes sense ;-) Thanks a lot Dave $\endgroup$
    – user2984629
    May 20, 2015 at 19:44
1
$\begingroup$

I'd suggest to get OpenSSL source, build it, and run it under debugger, watching exactly what "-text" is doing to private key. One could verify exponentiation operations with a calculator having big numbers capability. ASN.1/DER parser could be handy to see private key file.

Improve this answer
$\endgroup$
0
$\begingroup$

Have you played with OpenPGP / GnuPG (aka gpg)? gpg is a command-line tool similar to OpenSSL, but focused on end-user encrypting / signing, rather than on server / certificates / transport layer. You might find gpg suitably low-level for learning about keys -- that's where I started :-P

Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ If the private key contains the CRT parameters (used to optimize the private key operations), then rederiving the public key is fairly easy. In addition, even if the private key consists only of $n$ and $d$, then it is possible to rederive $e$ as long as it is not huge. $\endgroup$
    – poncho
    May 8, 2015 at 14:17
  • $\begingroup$ ok, thanks for the info. I'll have to do some more reading. $\endgroup$
    – Mike Ounsworth
    May 8, 2015 at 14:18
  • $\begingroup$ Oh dear, gpg sat close to me for years and I never thought of it. Thanks MikeOunsworth! $\endgroup$
    – user2984629
    May 8, 2015 at 15:37
  • $\begingroup$ Glad to be helpful! $\endgroup$
    – Mike Ounsworth
    May 8, 2015 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.