Are asymmetrical cryptographic keys fundamentally inter-convertible between the major key container formats? For example, can I convert an X.509 key file into a PGP or OpenGPG key file?
And--assuming the answer is yes--is it "security neutral" to keep one key pair in whatever format and convert into whichever container file format is needed for the occasion?
I'm getting a little tired of maintaining so many key pairs for X.509, OpenGPG, and SSH, when they're all RSA at the heart.
Yes and no: yes, the RSA keys embedded into certificates and privkeys are just numbers. You can extract them from the certificate and use them to build keys in other formats. This is commonly done to convert between different certificate formats.
PGP has some support for X.509 for S/MIME, but no ability to use X.509 privkeys verbatim.
SSH has some beta support for directly using X.509 keys and certificates.
You will found how to convert kes between these containers there:
http://sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG,-OpenSsh-and-OpenSSL
I'd also have a look at OpenSSL. It has so many different -in and -out functions that will likely be able to convert certs. from one type to the other.
Have a look at http://marc.info/?l=openssl-users&m=105162569405053&w=2
Related
I'm currently trying to use a CA Bundle with NodeJS 14.0. I've been using Namecheap's article as a guide the implement this feature. I'm currently stuck on a few things:
For the ca parameter for https.createServer(), what file formats are allowed to be passed in?
How do I check that a CA bundle is actually being used?
For the ca parameter for https.createServer(), what file formats are allowed to be passed in?
From NodeJS tls.createSecureContext:
Any string or Buffer can contain multiple PEM CAs concatenated together
Though, in general NodeJS uses PEM format.
How do I check that a CA bundle is actually being used?
You can use a certificate not signed by your CA, e.g. a self-signed certificate.
One point, possibly more subtle than you wanted: nodejs tls.createSecureContext internally calls OpenSSL PEM_read_bio_X509_AUX which actually accepts three PEM formats (or any sequence of those three formats, since nodejs loops). For two of them the base64/64cpl blob contains (exactly) an X.509 certificate, as respecified in rfc7468 sec 5, with either preferred label "CERTIFICATE" or deprecated label "X509 CERTIFICATE". In addition OpenSSL accepts a format of its own with label "TRUSTED CERTIFICATE" where the blob contains an X.509 certificate plus additional (ASN.1) data defined by OpenSSL; see e.g. the man page for d2i_X509_AUX online here. OpenSSL doesn't use this additional data for much, and of course nothing else uses it at all, so it's rare.
And to avoid confusion it might be worth noting that all OpenSSL PEM_read_ routines, including this one, skip any 'comment' data while searching for the PEM data, so actually a file/buffer that contains garbage, then a PEM cert, then more garbage, then another PEM cert, etc. will work the same as if it contained only the PEM certs.
Looking at LetsEncrypt FAQ page, they have clearly stated that email encryption and code signing require a different type of certificate and therefore they are not supported by LetsEncrypt.
My understanding is that https and S/MIME both require X.509 certificates. What is the difference between certificates these two technologies require?
Among other things (like the encryption key), an X.509 certificate also specifies what it may be used for. X.509 certificates for HTTPS and S/MIME usage basically have different usages.
The structure of an X.509 certificate is fairly complex. Its possible usage depends on attributes and extensions within the certificate, and require that specific combinations of them with specific values must be present.
For example, an S/MIME certificate, requires a Key Usage attribute with something like Encrypt, Verify, Wrap, Derive, a Key Usage extension that must have the Critical attribute set to Yes and include a Usage attribute with Key Encipherment plus in the Extended Key Usage extension (sic!) it should list the Purpose attribute value Email Protection.
Note that Key Usage extension Data Encipherment is not required, because in S/MIME, the data contents are encrypted by a random symmetric key which then is encrypted with the private key from the certificate. This is called hybrid encryption and it is done for performance and scalability reasons.
The certificate requirements even extend into the certificate chain, meaning that the certificate must be signed by another certificate that has been issued to sign certificates for that usage.
Note that the above example may not be 100% correct, because the subject is so complex, and I don't fully understand every aspect of it myself. I found this quote which I think describes the situation fairly well:
I think a lot of purists would rather have PKI be useless to anyone in
any practical terms than to have it made simple enough to use, but
potentially "flawed". — Chris Zimman
Resources that helped me:
X.509 Style Guide by Peter Gutmann: an attempt to shed light on the relations of attributes and extensions and their interpretations
RFC 4262 - X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities
I am not an expert (not even a novice :))) in security certificates and such - thus the question - but I was wondering if one can generate a new certificate by using a known fingerprint? :D (lost my certificate for a google play app and was wondering about this workaround)
Thanks.
This is practically impossible. The fingerprint uses a cryptographic hash like SHA-1 or SHA-256. With current technology it is impossible for a normal user to create the input which results in a specific hash value. It is doable with lots of efforts (i.e. still very very expensive) when MD5 was used for the fingerprint (not common), it might be doable by the NSA for SHA-1 and it is considered impossible to do it today for SHA-256.
Apart from that certificates are commonly not validated by the fingerprint but because a trusted CA has signed this certificate. This signature is part of the certificate so that you would not only need to recreate the certificate but also somehow get a valid signature which is impossible without having the private key of the CA which of course you don't.
I am looking for a strong encryption algorithm (already having generated a public key and private key).
I am using OpenSSL to generate RSA with 2048 bit key-length using an implementation in PHP. I just wanted to know how I can securely use the key for transmitting data.
What version should I use for RSA? How can I determine the version of RSA for the key generated by OpenSSL?
RSA encryption can be implemented using different padding mechanisms. To be precise RSAES-OAEP and RSAES-PKCS1-v1_5. These have been initially defined in different versions of PKCS#1, v1.5 and v2.0. I presume you mean this as "RSA version". There is also RSA KEM, which is probably the best mode to use for encryption, but it isn't used that much.
Both padding mechanisms however use the same keys. The only difference in keys is normally a key with or without CRT parameters. CRT parameters are used to speedup RSA private key operations 4-fold, they are generally included. The keys themselves do not specify for which padding mechanism they can be used.
It is however possible that the public key is embedded into a certificate that does specify different key usages. Even those however do not specify the padding mechanism itself.
So basically there is no such thing as an "RSA version" for keys.
If you can choose a padding algorithm, go for OAEP. Note that you should encrypt with the public key of the receiver, not a key from your own key pair. You should however use your private key to sign the encrypted data to make it unfeasible for an attacker to change the data in transit.
RSA private keys may be assigned a "passphrase" which - as I understand it - is intended to provide some secondary security in case someone makes off with the private key file.
How is the passphrase layer of security implemented?
ssh-keygen uses OpenSSL to generate RSA keys and store it in PEM format. The encryption you are talking about is specific to PEM. If you look at your key file,
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,5B01E932988DC66B
EPESt4ZVIrxnQXxxWWVa7cCR+vgNZ/4vTu4mdq6pjaW7jMZoB8HV+mA745mQkQw7
i+YtdVs/JqOeyGiw/3McxYYKZTlhyh7MvfIr1n8ZdZmcjQz+oFqMxChFU3r8BGgA
"DEK-Info" header has all the information you need to decrypt the key as long as you know the passphrase. "DES-EDE3-CBC" means Triple DES (in EDE mode). CBC is the chaining mode. The hex number is the initial vector needed for CBC.
PEM is a very old format so it only supports DES/TripleDES. AES and Blowfish were added later on but not supported by all implementations. My ssh (OpenSSH 5.2) only supports DES and TripleDES.
The passphrase is just a key used to encrypt the file that contains the RSA key, using a symmetric cipher (usually DES or 3DES). In order to use the key for public-key encryption, you first need to decrypt its file using the decryption key. ssh does this automatically by asking your for the passphrase.
If somebody got a hold of the key's file, they wouldn't be able to use it unless they knew the passphrase used to encrypt the file.
Private keys stored on general-purpose file systems (as opposed to tamperproof, special-purpose hardware tokens) could be easily stolen if not protected. File system permissions might seem sufficient, but they can often be bypassed, especially if an attacker has physical access to the machine.
A strong symmetric cipher, keyed with a good password, helps prevent this. A good RSA private key is too long to remember (for me, anyway), but far smaller symmetric keys can provide the same level of security. A relatively short, symmetric key stored in one's brain is used to protect a large private key stored on disk.