I am currently assuming that the keys are sent like this
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0
FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/
3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB
-----END PUBLIC KEY-----
Is that correct or is it in some other form
Superficially, they usually use either DER, or PEM, which is Base64-encoded DER. What you have in the question is PEM.
Internally, DER is a subset of TLV (tag-length-value), with fields that are relevant to RSA keys.
UPD: for the record, only public keys are sent over the wire during the SSL/TLS handshake process. There's no security risk in exposing those. SSL/TLS was designed specifically to withstand man-in-the-middle (read: Wireshark-style) attacks.
Related
I'm working migrating a Java app to NodeJS, they are using SSL and they gave me some files related with this:
www.domain.com.key
www.domain.com.csr
But I'm not an expert on this topic, and I'm trying to setting up the SSL certificate with Express but it seems a .CRT file is also required.
I asked them, but they told me that .CRT is actually inside of the .CSR file.
Not sure what should I do to make it work, I've been reading and doing lots of things without success, any idea?
Thanks.
The .key file is probably your PRIVATE key
The .csr file is a CERTIFICATE REQUEST probably signed with your private key
What you need is probably a .crt : a certificate corresponding to your csr signed by a certificate authority (or self signed, depending what you want to accomplish)
node (like another web server) is supposed to ask you 3 thing :
- your private key
- the certificate
- the certificate chain, eventually, depending of the certificate
What you can do is open with a text editor the different files, and see if you see the certificate inside:
you should see things like -----BEGIN CERTIFICATE----- or -----BEGIN PRIVATE KEY----- or -----BEGIN CERTIFICATE REQUEST----- , that will told you the exact content of the files.
This may sound a bit naive but I am missing something and I want someone to enlighten me.
To prevent man in the middle attacks where your password in plain text could be easily read, client Side Encryption is done where the password is encrypted so a man in the middle can only find data which is gibberish for him. However, for the encryption, the server needs to send a key over the network.
So, my question is, if a man in the middle attack occurs, then he would be able to see the key as well which was sent for the encryption on the client side. With the key in his possession, the encrypted password can be very easily decrypted. Hence, the whole purpose of the encryption is defeated.
What am I missing here?
First, a precision: the attack you are talking about is not a MITM but passive eavesdropping. In a MITM, the attacker relays back and forth messages from the two parties.
Sending a symmetric key along with the encrypted data would of course be silly as an eavesdropper would sniff it as well as the data. This is why asymmetric encryption (aka public key encryption) is used.
In asymmetric cryptography, ciphers do not operate with a single key but with a key pair, composed of a public key and a private key. Public and private key are created together at the same time using a special algorithm and they are strictly connected to each other. The client encrypts the data with the server's public key, which is the only key that is shared publicly; this data can only be decrypted by the server with the server's private key. The communication from the server to the client is done in the same way.
You might want to read about PKC here:
https://enigmail.wiki/Introduction_to_Cryptography,_PGP,_and_Enigmail
https://en.wikipedia.org/wiki/Public-key_cryptography
It is worth noting that a MITM attack can actually happen at the moment one of the parties shares his public key with the other:
First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to Alice that claims to be from Bob, but instead includes Mallory's public key.Alice, believing this public key to be Bob's, encrypts her message with Mallory's key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. When Bob receives the newly enciphered message, he believes it came from Alice. [Wikipedia]
This is actually the weak point of PKC; the solution is either to use a centralized Certificate Authority (this is how it is done for the SSL certificates used in HTTPS), or use a shared Web of Trust. Both solutions have their advantages and drawbacks.
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.
A few similar threads exist but none has a checked answer or much discussion. I'm trying to setup an https server on express js but I'm getting
crypto.js:100
c.context.setKey(options.key);
^
Error: error:0906D06C:PEM routines:PEM_read_bio:no start line
I generated my .csr and .key files with
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out myserver.csr
One suggestion was to convert the .csr to a .pem by following these instructions: http://silas.sewell.org/blog/2010/06/03/node-js-https-ssl-server-example/
That didn't work.
The express.js docs (http://nodejs.org/api/https.html) show both of these files as .pem, however. If that's the issue, how would you convert a .key file to a .pem? This threat is partially helpful How to get .pem file from .key and .crt files? but if anyone knows what expressjs requires, I feel that's the missing component.
How would I check that the files are properly in ANSI, or convert them if not?
There is also some discussion on whether the file should begin with -----BEGIN ENCRYPTED PRIVATE KEY----- or -----BEGIN RSA PRIVATE KEY-----
Any help is greatly appreciated.
So i think there's at least a little bit of terminological confusion, and the node.js example you have there doesn't help by renaming everything to .pem.
Here's a general overview for how SSL works:
You generate a pair of public and private keys. For our purposes the former is your "certificate signing request" (CSR for short) and the latter is your private signing key (just "your key").
If you wanted to generate a self-signed certificate (this is useful for local testing purposes) you can turn around and use your key and your CSR to generate a certificate. This link http://www.akadia.com/services/ssh_test_certificate.html has a pretty clear run down of how to do that on a *nix based system.
For the purposes of web browsers, SSL certificates need to be co-signed by a trusted authority, e.g. a Certificate Authority (CA). You pay a CA to co-sign your cert, and vouch for your authenticity with browser vendors (who will in turn display a green padlock for your site when your website presents its certificate to browsers).
The co-signing process starts with you uploading your CSR to your CA. They will then take that CSR and generate your certificate. They will then provide you with a couple of certificates, your certificate, their root certificate, and possibly some intermediate certificates.
You then need to form a combined certificate that proves a chain of authenticity back to browsers. You do this literally just by concatenating your certificate, followed by the intermediate certificates (in whatever order was specified) ending with the root certificate. This combined certificate is what you hand to your web server.
In order to enable your web server to serve over SSL, you need to hand it your (combined) certificate as its public encryption key (which it provides to web browsers upon request), and your private encryption key, so that it can decrypt the traffic sent to it by web browsers.
So. Now with all of that in mind, you should take that CSR that you have and provide it to your CA, and get the various certificates back, concatenate them, and then use that w/ your private key in your express server.
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.