3

I want to write an API, based on OpenSSL, that can convert an RSA private key stored as DER to the PEM format. I'm just wondering if a DER key can be password-protected. I've searched the OpenSSL documentation and found out that it can only protect a key with the PEM format, but is it a restriction of OpenSSL or is it basicallly nonsense to password-protect a DER key ?

Cyrille
  • 133
  • 3

2 Answers2

1

but is it a restriction of OpenSSL or is it basicallly nonsense to password-protect a DER key ?

It makes a sense to protect a key with a passphrase but this requirement does not arise when using OpenSSL format with DER encoding, as encryption is not then supported.

  • Ok ,so the restriction works both ways. That means that I won't be able to convert a passphrase-protected DER key to PEM with OpenSSL, right ? – Cyrille Oct 21 '15 at 13:05
  • Yes, obviosuly @Cyrille –  Oct 21 '15 at 13:10
1

OpenSSL's original or 'legacy' (per-algorithm) privatekey formats can only be encrypted (PBE) in PEM format not DER, but the newer PKCS#8 format can be PBE in either PEM or DER, and PKCS#12 is automatically PBE and always DER (PEM is not defined for it). PKCS#8 and PKCS#12 are also better functionally as they handle multiple algorithms automatically without the user's help. You do have to keep track of whether PKCS#8 DER files are encrypted, because you don't have the PEM header to say "BEGIN PRIVATE KEY" versus "BEGIN ENCRYPTED PRIVATE KEY".

PKCS#8 has been implemented since about 2000 AIR, but through 0.9.8 legacy formats were used by most commandline functions other than pkcs8; for 1.0.0 and up (since about 2010) many but still not all commandline functions use PKCS#8.

Look at the d2i/i2d routines, and PEM_read/write routines, for PKCS8PrivateKey rather than {RSA,DSA,EC}PrivateKey. Also look at the PKCS12_* routines if interested, but it's a good deal more complicated. OTOH it is also more widely used and interoperable, if that's of any benefit to you. (PKCS#12 is also called PFX by Microsoft and some others.)

dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28
  • Thank you for these clarifications, this is most helpful. So if I don't know the format of the key (RSA, PKCS#8, PKCS#12), I guess I will have to try the conversion for each format until the execution returns something intelligible. – Cyrille Oct 23 '15 at 08:14
  • Regarding PFX and "interoperability", [here](https://www.cs.auckland.ac.nz/~pgut001/pubs/pfx.html) is a hilarious take on PFX, which has apparently been assembled in a rather haphazard fashion. Looks like that "format" is best avoided. – David Tonhofer Jan 01 '16 at 20:12
  • 1
    @DavidTonhofer That page is from 1998. Although PKCS#12 is indeed complicated and confusing, even more than most ISO/CCITT/ASN1 committee camels, by using a little common sense everyone has implemented SHA1+TDES for privatekey (and equally common though less sensible SHA1+RC2-40 for certs) and it works easily and reliably for Windows NSS/FF Java and OpenSSL to my knowledge and Apple and gnuTLS to my understanding. If you know any non-toy application of PKC *with X.509 certs* (excludes SSH PGP DNSSEC and some IPSEC) *with movable/sharable keys* (excludes HSM and some others) ... – dave_thompson_085 Jan 06 '16 at 20:25
  • 1
    ... that doesn't support PKCS#12 at least as an option, I'd be very interested to hear about it. If you look at the rest of his site PG also considers X.509 unusable and unsafe, so you probably shouldn't connect to any public websites -- including SE. – dave_thompson_085 Jan 06 '16 at 20:27