A fair number of people have asked about how to parse
old-fashioned OpenSSL PEM private keys (including encrypted ones)
to use them directly in .NET for signatures or encryption.
It is more secure to use pkcs #8 or 12, but those older PEM
private keys seem to be still used a lot!

Here is a C# console utility I wrote recently to do just that:
http://www.jensign.com/opensslkey

It parses either private PEM RSA key files (encrypted or unencrypted)
and the simpler PEM public keys (which are just b64-encoded
X509 SubjectPublicKeyInfo formatted with headers/footers).
The code shows how to directly asn.1 parse out the key components,
and removal of the leading (high-order) zero bytes in the key components.
The key data is then used to instantiate an RSACryptoServiceProvider.

Optionally all the key components are displayed after decoding (or
decrypting). For RSA private keys, optionally the keypair can be
exported to a pkcs #12 file. This is accomplished by creating
a transient unsigned x509 certificate linked to the keypair (which
is also not persisted).

- Mitch Gallant
MVP Security

Hello!
You wrote on Thu, 13 Apr 2006 02:09:32 -0400:

MG> A fair number of people have asked about how to parse
MG> old-fashioned OpenSSL PEM private keys (including encrypted ones)
MG> to use them directly in .NET for signatures or encryption.
MG> It is more secure to use pkcs #8 or 12, but those older PEM
MG> private keys seem to be still used a lot!

I must disagree on one thing - they are not "old". This is the default
standard on all non-microsoft systems. And also, many people use PEM for key
transfer because the format is textual (so the keys can be sent by IM or
pasted into e-mail).

With best regards,
Eugene Mayevski

Sorry .. i didn't mean to imply that in a negative way.
I was using some of the "old" jargon at:
http://www.openssl.org/docs/crypto/p...RYPTION_FORMAT
" ..This old PrivateKey routines use a non standard technique for encryption .."
- Mitch

"Eugene Mayevski" <mayevski (AT) eldos (DOT) com> wrote

Hello!
You wrote on Thu, 13 Apr 2006 09:07:39 -0400:

MG> Sorry .. i didn't mean to imply that in a negative way.

It's not negative, just maybe a bit confusing for somebody .

MG> I was using some of the "old" jargon at:
MG> http://www.openssl.org/docs/crypto/p...RYPTION_FORMAT
MG> " ..This old PrivateKey routines use a non standard technique for
MG> encryption .." - Mitch

I think they meant not format, but routines themselves.

Interesting thing is that, while PEM format (for security in general, not
the key format) itself didn't get wide adoption, it was about to become
mandatory in some countries (don't know the real situation though).

With best regards,
Eugene Mayevski

"Eugene Mayevski" <mayevski (AT) eldos (DOT) com> wrote

I didn't realise PEM was a standard. I thought it was a proprietary format
for OpenSSL.

Where is the documentation for the standard?

I've been looking to write conversion routines from PEM to the more portable
PKCS #12 for a while, and have not been able to find documentation of the
format.

Finding documentation for PKCS #12 is easy, but I don't have much luck with
my searches for documentation for PEM. Perhaps it's not an open standard.

[And I can't believe that the non-Windows world has stayed so far in the
past that they still can't encode binary files for inclusion into IM and
email. Last time I was a Unix developer, uuencode had been around for quite
a few years.]

Thanks,

Alun.
~~~~

"Mitch Gallant" <jensigner (AT) community (DOT) nospam> wrote

For those of you relatively new to certificate handling, the reason that
Mitch only wrote the export code for PEM files with private keys in, is that
there's a trick for converting PEM files that don't have private keys in
them.

Just rename the file from a .pem extension to a .cer extension, and you have
a certificate that can be imported into any of the Windows certificate
stores!

Alun.
~~~~

Hello!
You wrote on Thu, 13 Apr 2006 08:09:14 -0700:

AJ> I didn't realise PEM was a standard. I thought it was a proprietary
AJ> format for OpenSSL.
AJ> Where is the documentation for the standard?

RFC 1421-1424

With best regards,
Eugene Mayevski

"Eugene Mayevski" <mayevski (AT) eldos (DOT) com> wrote

Very light on actual details and examples - I did a quick search for "BEGIN
RSA PRIVATE KEY", for instance, and didn't find it. Perhaps this is part of
the X.50* standards that I don't have access to.

The only reference to "BEGIN" as part of the RFCs you list is in examples of
the message format itself - "-----BEGIN PRIVACY-ENHANCED MESSAGE-----"

Alun.
~~~~

Dont' really want to turn this into a "standards soap-box" thing ;-)

but ..
I don't mind calling these PKCS8 PEM encapsulations as "sort of" standards:
PKCS #8 EncryptedPrivateKeyInfo Encrypted Format:
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIICojAcBgoqhkiG9w0BD .....

PKCS #8 PrivateKeyInfo UNEncrypted Format:
-----BEGIN PRIVATE KEY-----
MIICdgIBADANBgkqhkiG9w0B ......


but this one ??
Private Key (Traditional SSLeay RSAPrivateKey format) Encrypted:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,24A667C253F8A1B9

Will be updating opensslkey.exe to include the pkcs #8 PEM parsing also,
(since it is easy in .NET 2 :-)

Rgds,
- Mitch Gallant


"Alun Jones" <alun (AT) texis (DOT) invalid> wrote

Hello!
You wrote on Thu, 13 Apr 2006 12:21:12 -0400:

MG> but this one ??
MG> Private Key (Traditional SSLeay RSAPrivateKey format) Encrypted:
MG> -----BEGIN RSA PRIVATE KEY-----
MG> Proc-Type: 4,ENCRYPTED
MG> DEK-Info: DES-EDE3-CBC,24A667C253F8A1B9

Exactly. This one is from RFC 1421.

With best regards,
Eugene Mayevski