What is the recommend way and best-practice to send private keys and SSL private keys? I was thinking of zipping up the files, then using gpg:
gpg -c thefile.zip
The problem then becomes how do you send the passphrase used to encrypt to the other end? Is there a better solution?
TL;DR: private keys are called private for a reason.
You can secure private keys by not transmitting them at all.
EDIT: For the stated use case of private keys for a hosting provider, you are still better off generating them in place.
GPG can allow you to send these securely without having to send a passphrase. If the destination has their own GPG key, you can encrypt the file so that only they can open it.
For example, the following command will allow me to only open thefile.zip with my GPG key without either of us ever communicating a passphrase.
gpg -e -r E9053BDA thefile.zip
Alternatively, this command will zip and encrypt all *.crt files in one command.
gpg-zip -e -r E9053BDA *.crt
Documentation Reference:
For transmitting keys privately in any secure manner (or any keys/passphrases you encrypted them with), you have no chance but using a pre-established trusted, secure channel from the start.
Depending on your needs and the possibilities available, this might include
What method to actually use completely depends on your needs, and potential eve-droppers. If governmental institutions and secret agencies are possible attackers, most of those ways will be compromised from the start: neither phone, nor snail mail will be secure any more -- and possibly others.
If you just want to communicate with somebody else, both ends should generate their own key pairs, distribute the public key while keeping the private key private. You still have to exchange information on the public keys, for example the fingerprint, through a pre-established, trusted channel like described above.
First, read what Deer Hunter wrote above. The best way to securely send private keys is to never send them in the first place. Full stop.
That being said, there probably are some circumstances in which you might legitimately need to transfer some private key/s that exist in your hands & and in one location to some one else's hands in another location. You should minimize these times as much as you can, preferably by just walking the client that needs them through generating the keys themselves. But there may be some times when that's not practical for some reason (or, more likely) it's not your call to make. So, what do you do then?
Well, you do what governments and tech firms do when they need to distribute very sensitive encryption keys (if most often in symmetric or even in one-time pad key distribution scenarios, rather than with asymmetric private keys) out to a remote location: you:
(1.) Encrypt the hell out of the key/s to be transferred before it/they ever leave your facilities, using a unique "outer" key created only for one transfer and then destroyed. If that protective encryption key is generated from a password or pass-phrase, the password or phrase meets very high strength requirements.
(2.) Use a channel with much better security than existing, general-purpose networks--aka the Internet!--to get the encrypted package to its destination. Physical delivery of a memory device containing the encrypted key is the simplest but not always most practical channel.
(3.) Keep the "outer" key that unlocks the protective encryption (or a password/passphrase that forms the basis for the key) in your possession until it's time to transfer the key/s you want to transfer and then decrypt them at clients's location. That means either you being at the key transfer event in person to decrypt the protective encryption, or sending the key that unlocks the protective encryption using another, independent high-security electronic channel to get it to client's place at decryption time.
(Why not just skip to #3 and send the original private key you need to move to the client by that highest-security electronic channel? Because we don't trust any one channel, not even what we think is one that has especially-good security, nearly enough to handle info like a private key. We make a possible opponent intercept at least two channels/mechanisms of transfer, and we make it difficult to intercept anything useful from either one, let alone both.
Now, that all sounds arduous and complicated. But in reality it doesn't at all necessarily need to be either. (Assuming we're in a common, this-key-is-important-but-it-wouldn't-be-truly-catastrophic-if-it-was-compromised situation.) For example you could:
-Use a well-regarded hardware-encryption protected USB device--no lack of options out there-- for transport. Write private key to that, lock it with a unique strong password/code/phrase, and drive it across town to client's location that needs the key. Plug it in when you get there, unlock it, and copy the private key to client's system.
-Grab a new (not previously used) ordinary USB stick. Use a software program you have strong trust in to encrypt the private key in a file. Transfer file to the USB. Then double-check USB--just to be sure-- that the only thing on it is the now-encrypted package. Do registered mail or FedEx to get it to client's site. When it arrives, use Off-the-Record or a similarly-security messaging app like it to convey the key to the protective encryption (or password/phrase needed to re-generate it) to client, who then decrypts & gets the private key.
-Need to be able to repeatedly distribute keys to a client, on-demand and electronically? Encrypt private key in file as in last example. Have a simple-but-secure VPN or SSH-access server that you only use for encrypted key file distribution, that client have pre-shared auth information to login to, and that you normally keep disconnected from any remote access. When client calls you and tells you he's ready to receive the key, transfer it from your internal storage environment to the server. Enable remote connections to server from client's ip address. Client connects and grabs encrypted key file. Finally, you then use high-security messaging app (or whatever) to transfer the protective key to your client.
Lots of options. It's true that there's some work involved in each if you want the transfer to be well-secured. Turned-off by the prospect of doing the work? That's understandable. In that case, see point #1 (the original point Deer Hunter made): create a technological arrangement where you don't need to transfer private keys at all.
The proper way to do this in an unsecured channel is to use a public key infrastructure to send a private key.
1) The receiving party generates a public/private key pair.
2) The sending party will then use the public key of the receiving party to encrypt The Private Key and send it. This encryption can only be decrypted by the receiving party's private key which only the receiver knows. This way the private key can be sent in a secured manner over un-secured channel.
There is more to this to consider: How can the receiver ensure the identity of the sender? In order to do this, the sender also has to generate a pair of private/public key.
The sender after encrypting "The Private Key" with the receiver's public key, the sender will has to encrypt the result with his/her private key to generate the final message before sending. After receiving the message, the receiver will then need to first decrypt the message with the sender public key. If successful, he can assure that the message is authentic.
Let K be The Private Key needs to be sent, E is encryption, D is decryption
Sender: Message M = E(E(K, pub-k-receiver), pri-k-sender)
Receiver: K = D(D(M, pub-k-sender), pri-k-receiver)
Now the receiver has to worry whether the message is fresh, i.e. no some kind of old data that a third party intercepted and replay at a later time. Usually a timestamp is embedded into the message M to solve this problem.
Sender: Message M = E(E(K + timestamp, pub-k-receiver), pri-k-sender)
Receiver: K = D(D(M, pub-k-sender), pri-k-receiver) - timestamp
Generally you shouldn't send private keys, but if you absolutely have to send a private key then encrypt it with the recipient's public key. Bear in mind that your recipient must be willing to take the risk that you could keep a copy of the private key.
If the key being shared is not too long, and the thing it is protecting is not too secure, one easy way to share a key is to simply read it aloud over a relatively secure voice communication service such as whatsapp.
As long as both parties can trust each other, such a method ensures that no 3rd copy of the key exists. This is what my team used to share things like API keys and passwords for shared accounts when we were very small.
As others have said, such keys should not be used for an extended duration after being shared in such a manner.
I will reiterate what others have said first, then add one more point.
What has been said:
Share only public keys if possible - this is how security works.
If private keys must be shared, don't send through shared infrastructure (note that cell phones and land lines are not completely safe).
If keys must be sent through shared infrastructure, properly encrypt as well as using secure channels. Consider sending a part through two different channels.
Best if the shared keys are not used too long.
And one new thought:
Consider additionally using steganography for communications with people you often interact and share photos with, it will be harder to spot.
But to reiterate, systems like Bitcoin are strong because private keys are not shared, requiring each account to be broken individually. Systems with shared keys expose everyone to single breaks, or single mistakes across the group.
Send the private key from an anonymous emailer service to a 48-hour throwaway email service address. You just need to publicly post your throwaway email address with the public-key in full sight of everyone and wait for your sender-partner to send you the PK within 48 hours. After 48 hours the throwaway evaporates. No one needs to trust anyone. The two parties could always use the same PK for any future messages without going through this transaction ever again. However, that is less secure doing it that way.
