We are trying to decide on which RSA key format our application should use. The ideal format would be widely used and supported in most of the popular platforms/frameworks. This would make it easy for 3rd parties to integrate with our system. So which one of the RSA key formats is closest to that?
-
- Are you talking about public keys or private keys? 2) Probably one of the SSH formats. Unfortunately there are several...
– CodesInChaos May 01 '14 at 10:27 -
I am interested in both public and private keys. Thanks for response, I will have a closer look at SSH formats – SoftwareFactor May 01 '14 at 11:14
-
The key format used by PGP is another alternative – CodesInChaos May 01 '14 at 11:40
1 Answers
For private key storage, you will find mostly:
What OpenSSL does. This actually is the ASN.1 format specified at the end of PKCS#1 (type
RSAPrivateKey). When that object is Base64-encoded into PEM format, the header will be:-----BEGIN RSA PRIVATE KEY-----. The raw (binary) format is "as is", but PEM includes options for symmetric encryption (with a key or a password). This PEM format is not really standardized or documented; it is "what OpenSSL does".PKCS#8. For a RSA key, it will be a wrapper around the ASN.1 format from PKCS#1, with an explicit specification of the key type (i.e. "this is RSA"). PKCS#8 also includes options for symmetric encryption. OpenSSL also supports PKCS#8 and can encode it into PEM, this time with the header:
-----BEGIN PRIVATE KEY-----(notice the difference with the previous case: the key type is no longer specified in the PEM header, since the ASN.1 structure contains that information). While a PKCS#8 file which is PEM-encoded could contain PEM-level encryption, this is rarely done since PKCS#8 can also do it internally. PKCS#8 benefits from support in many frameworks, e.g. Java knows that format natively.PKCS#12, also known as "PFX". This is in fact a generic archive format which features optional encryption and integrity checks, and can be used to put together one (or several) private keys and the corresponding X.509 certificates. If you store public keys in certificates, then you will want to use that format since it is natively known by many systems (Windows and MacOS X can read it directly, for instance).
The OpenPGP format. This is what will be used in most "keyrings" as handled by GnuPG. It is not based on ASN.1. If you have to reimplement it yourself, then it is somewhat simpler to manage than PKCS#8. This format is rarely known natively by existing programming frameworks, but ready-to-use opensource libraries are available (e.g. GnuPG or Bouncy Castle).
What OpenSSH supports. SSH has long used its own formats, but for private keys, OpenSSH can feed on the OpenSSL formats (both the OpenSSL-specific and PKCS#8).
For public keys, there are a few twists:
In the OpenSSL and X.509 worlds, public keys don't exist "as themselves" but only as part of X.509 certificates. You may want to store your public key in a certificate structure, which could be (by tradition) self-signed, since there is a "signature" field in the X.509 certificate format. The part of a certificate which contains the public key itself is called
SubjectPublicKeyInfo(look for it in the standard) and is a wrapper around an algorithm-specific format, which brings us back to PKCS#1. DER-encodedSubjectPublicKeyInfostructures are occasionally spotted in real-world applications, but they are quite rare.OpenPGP has its own formats for public keys.
OpenSSH has its own formats for public keys. Mind the plural: there are several. Start here for descriptions.
For interoperability and integration, I'd say that it is a tie between X.509+PKCS#8 (with possible use of PKCS#12), and OpenPGP. Personally, I'd use the former, but that's mostly out of habit.
- 326,555
- 60
- 792
- 962
-
Nit: PEM label
BEGIN/END PRIVATE KEYis PKCS8 clear (PrivateKeyInfoin section 5) whileBEGIN/END ENCRYPTED PRIVATE KEYis PBE (EncryptedPrivateKeyInfoin section 6). (These are made official by RFC7468, a year after this answer.) And update: as of 2021, the JSON-based format JWK, which with JWA forms the basis of JWS, JWE, and JWT, has become quite popular and widespread. – dave_thompson_085 Jun 21 '21 at 01:25