What is the recommended RSA key format to use if you only started using it nowadays?
I know that PKCS#1 is a format dedicated to RSA keys but do I need to avoid using it because it's old?
recommended RSA key format to use will be PKCS#1, PKCS#8 or PKCS#12 ?
TL;DR: Use PKCS#1 only within your own identified scheme, use "inner" PKCS#8 / SPKI if you want to identify a key in a scheme. Use encrypted PKCS#8 when storing private keys and no better method is available; use PKCS#12 if you want to accomplish the same thing and you are using PKIX / X.509. PKCS#12 can also be used as a trust store, usually using a separate file.
I'll cover this because it is more about choosing an encoding than the inner working of RSA and other algorithms. If that wasn't the case then it should be posted on Cryptography, after searching for an answer on that Q/A site, of course.
First, here are the standards that we are talked about. They have been initially been created by RSA Laboratories, but currently they are being maintained as RFC's:
Another important document (or really set) was initially created by ITU-T, formerly known as CCITT, an international treaty organization:
However, the X.509 standards are quite large and complex, and back when they were new cost money to obtain, so IETF (the Internet Engineering Task Force) created a series of RFCs that form a "profile" (effectively, a subset) of X.509 for Internet use, called PKIX (Public Key Infrastructure using X.509). The main one here is:
First note that these standards are not independent of each other. PKCS#12 depends on PKCS#8 to encode the private key and X.509/PKIX to encode the certificates within this "container format". PKCS#8 depends on PKCS#1 to encode the private key when it is an RSA key (pair), and X.509/PKIX similarly uses PKCS#1 for the public key. PKCS#8 originally used PKCS#5 (not listed above) for password-based encryption, but PKCS#12 defined additional password-based encryption schemes, and now both PKCS#8 within PKCS#12 and "standalone" PKCS#8 frequently use either the PBEs from PKCS#12 or the "PBES2" scheme from PKCS#5v2 (that v2 is critical; the PKCS#5v1 schemes are now broken and obsolete).
These structures can and often are stored in text rather than binary, in which case the specifications of PEM in RFC 1421 and the extensions for PKIX related structures in RFC 7468 should be consulted.
Now comes the question which one to use. However, before we talk about storing private keys: private keys have been designed to remain private. That means that you should choose the most secure method of storing and using them (that still would help fulfill your use case). Quite often it is better to generate and store private keys within a secure container such as a hardware device (HSM, TPM) or a system provided certificate- or key store.
After that it depends on what you are trying to achieve.
PKCS#1 describes a simple, near-minimal format for an RSA public or private key. So if you're handling raw private keys and need to store them on a medium, you need some way to encode the key. This is why the leading RSA specification contains a method of encoding them. So you'd use this standard when you'd work with RSA on a relatively low level, basically when you'd have to specify your own protocol (which you should do if you'd use RSA at such a low level, cryptographic protocols should deserve their own specific section in the documentation).
Notes:
EVP_BytesToKey function with ONE iteration of MD5; see numerous Qs on the crypto and security Stacks about how bad this is).The inner format within PKCS#8 would be used if you need a way to identify the private key while using the binary construction. Basically it is a sequence of the key type followed by the key value. The key type consists of an algorithm identifier, which is encoded as an OID plus optional parameters. The original, and for a long time only, OID for an RSA key is defined in the PKCS#1 specifications:
The object identifier rsaEncryption identifies RSA public and private keys as defined in Appendices A.1.1 and A.1.2. The parameters field has associated with this OID in a value of type AlgorithmIdentifier SHALL have a value of type NULL.
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
Which means that the key is specified using 1.2.840.113549.1.1.1. Note that this doesn't indicate the algorithm to be used for that key. OTOH PKCS#1 (now) defines different OIDs for OAEP and PSS and their related parameters in that same appendix, and RFC4055 directs the use of those OIDs and parameters in public keys in PKIX certificates -- and 4055 is standards track while 8017 is not. [DaveT note: I suspect the statement about always using rsaEncryption is a leftover from v1 when it meant that the key didn't specify a signature hash like sha1withRSA.]
Another reason to choose PKCS#8 is a requirement to use a standard, documented, and (potentially) strong encryption for your private key. (PKCS#8 specifies the encryption with a very general AlgorithmIdentifier syntax, so it is possible to use a weak encryption algorithm, or a low and inadequate iteration count; however most software won't do so by default.)
As indicated, PKCS#8 encoded information can be put within PEM headers. For the "inner" PKCS#8 structure the header "PRIVATE KEY" is used. For the encrypted "outer" structure the header "ENCRYPTED PRIVATE KEY" is used. (Both of these are in RFC7468, cited above.)
SPKI is an acronym for SubjectPublicKeyInfo. It is the main method within the X.509/PKIX specification to describe a public key. It is almost identical to the "inner" PKCS#8 structure in the sense that it simply consist of a sequence of an algorithm identifier with the value of the public key. Usually the same algorithm identifier is even used for both the public and the private key. As with PKCS#8, the sole purpose is to be able to identify the key type.
These keys can be encoded within PEM, and they then would use "PUBLIC KEY" in the header analogous to "inner" PCKS#8.
X.509 (or its Internet form, PKIX) specifies the certificate format used for instance for TLS, but also for CMS (the cryptographic message syntax originally specified in and still sometimes called PKCS#7) as well as S/MIME (the standard for secure email based on CMS) and many other protocols such as XMLenc and XMLdigsig but also code signing etc. etc. X.509 certificates can be used to create a PKI, a public key infrastructure. Certificates are the main method of distributing and trusting public keys. When creating a key pair, the public key is quite often simply stored within a certificate that also contains information about the holder of the certificate which can be a human, a "role" or system such as server.
For RSA to work it is usually required to not just have the public key but to establish trust in the public key. Otherwise you'd not know who's public key you would be using to verify a signature, or who you are encrypting data for. For that reason most protocols that have multiple entities must have some way of establishing the identity of those entities. Although there are other ways of establishing trust, X.509 is the most common hierarchical method of establishing trust, relying on trust of Certification Authorities to indicate trust of underlying parties and their certificates.
X.509 certificates are often encoded to text as well, which is unfortunately not directly indicated by the file extension (so a .cer, .crt, .cert or whatever can contain a binary encoding or textual encoding. Multiple (trusted) certificates are sometimes present in a single file as well. Certificates are indicated using the X.509
PKCS#12 is what cryptographers usually call a container format. It contains a description of storing various cryptographic elements and, of course, a way of establishing what is stored and how to retrieve the information. PKCS#12 is is commonly used in two ways:
Usually PKCS#12 files are used if a more secure method of storing these items such as the aforementioned hardware devices or key stores are not present. They offer protection by allowing the information including private keys and certificates to be encrypted using symmetric cryptography.
© 2022 - 2024 — McMap. All rights reserved.