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?

  • 13
    What are you trying to achieve by having private keys in two or more places? Commented Sep 30, 2015 at 18:39
  • 11
    There is no private key in an SSL certificate, but more importantly there is something wrong with the question. You shouldn't be sending private keys around in the first place. If they aren't private to one entity they cannot be used for the purpose for which they were designed and created.
    – user207421
    Commented Sep 30, 2015 at 22:55
  • 9
    @EJP That's not true. An SSL certificate is a public (for the browser/client) and private (for the server) pair just like an SSH key or PGP key. Additionally, there are many times when you are forced to send them around. For example, my company uses a CDN which certainly doesn't give us SSH access to their servers. Instead we have to procure the SSL Certs, and provide them with the public/private pair to provision on their systems. In our case, we use a different pair for our systems than for theirs in order to separate the consequences of exposure of the public key.
    – akraut
    Commented Sep 30, 2015 at 23:50
  • 8
    RFC1149 - the only way for messages to fly securly
    – WernerCD
    Commented Oct 1, 2015 at 0:43
  • 4
    An SSL certificate is not really a key pair. You can examine the certificate chain in your browser whenever you connect to a server using SSL, but, obviously, not the private key. However, phrases like "generate a certificate" are often used sloppily to mean "generate a key pair and sign a certificate request".
    – armb
    Commented Oct 1, 2015 at 15:58

9 Answers 9


TL;DR: private keys are called private for a reason.

You can secure private keys by not transmitting them at all.

  • If you have shell access to the server they are used at, you simply generate them in situ.
  • If the target device is too weak/underpowered to generate the keys, it is also too weak to use asymmetric encryption (this includes entropy sources). Of course, there are memory-constrained hardwired devices (smart cards, for instance), but you can use a physically secure link to move the keys into them without being connected to the Internet. A rather obscure corner case is asymmetric encryption used in a remote device (read: a space probe or a satellite) but the conditions are unlikely to be met in practice (one key compromised but another secure link still available).
  • If you don't have secure shell access (SSH) to the target device, you generally cannot securely copy (SCP) the files. Using email to move the keys, even in an encrypted form, draws unwarranted attention to the message and leaves the trail in perhaps dozens of places across the Internet.
  • Sending the keys means the people at the other end of the channel must trust you and you must trust them. It is not always a good proposition in business and other high-stakes environments (either party can forge communications with the private keys in hand).

EDIT: For the stated use case of private keys for a hosting provider, you are still better off generating them in place.

  • 3
    I +1'd this because it's right, but I question whether it's practical for some uses like TLS certs at this point. Let's Encrypt might make it practical though. :-) Commented Oct 1, 2015 at 3:24
  • It's common for smart cards to be able to use asymmetric encryption, but be provisioned with keys generated off the device. (Obviously at least the first key has to be protected by something other than asymmetric encryption when there is no existing private key on the card.)
    – armb
    Commented Oct 1, 2015 at 16:05
  • @armb - keys are fed through a secure physical channel. Commented Oct 1, 2015 at 16:21
  • @DeerHunter there are generally secret keys involved as well, but the starting point is that a secret on the card is known to the provisioner. (Or at least can be derived from the combination of a secret known to the provisioner and public information about the card.)
    – armb
    Commented Oct 1, 2015 at 16:31
  • The Jenkins SSH Credentials Plugin asks you to enter private ssh keys via https web form and transmit them (via POST). Are you saying this is bad practice? The Jenkins SSH Credentials Plugin is widely used by developers.
    – cowlinator
    Commented Mar 10, 2020 at 20:33

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:

  • Trying to run gpg -e E9053BDA myfile.zip I am getting: usage: gpg [options] --encrypt [filename]
    – Justin
    Commented Sep 30, 2015 at 18:37
  • 1
    Whoops, I edited my reply. I forgot -r which specifies the recipient. There are other options, you can add to. Like --sign/-s which also signs the message with your key. This lets the recipient ensure that the message came from you and not someone else.
    – akraut
    Commented Sep 30, 2015 at 18:39
  • So how do I the destination generate my own GPG key? Then, do I just send it to the other end?
    – Justin
    Commented Sep 30, 2015 at 18:40
  • 1
    Usually, you'll need a key for both ends of the communication. gpg --gen-key will generate one. If you're unfamiliar with GPG, I suggest checking out the Getting Started chapter of the GPG Handbook.
    – akraut
    Commented Sep 30, 2015 at 18:43
  • 4
    This really is the right answer.
    – dotancohen
    Commented Sep 30, 2015 at 22:16

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

  • sending encrypted mails to an address you already have trusted public keys for, no matter whether OpenPGP or S/MIME
  • sending them using (snail) mail, sealed if necessary
  • traveling in person, if necessary comparing official IDs
  • secure upload to a trusted machine, for example using SSH
  • sending an encrypted mail, while transmitting the passphrase through another channel (phone, text messate)

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.

  • I'd personally say transfer them over a phone call than text. When you think about it, it's a lot cheaper/takes less storage for an organization to record all of your text messages than for them to record all of your phone calls. Both be hacked fairly easily, so neither may be a good choice Commented Sep 30, 2015 at 22:25
  • 1
    Appreciate the outside-the-box thinking with this answer. A secure channel doesn't HAVE to be electronic. Putting the key on a thumb drive and overnighting is a great solution in a lot of cases. Commented Oct 1, 2015 at 21:54

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

  • 1
    you forgot the key exchange problem. Sender & Receiver need to first establish trust before they can encrypt. Some people add fingerprint to their business card to verify the key.
    – vimdude
    Commented Oct 18, 2017 at 13:38
  • "After receiving the message, the receiver will then need to first decrypt the message with the sender public key" This does not work! You need the private key for decryption, the public key will not suffice. Commented Apr 20, 2021 at 13:36

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.

  • Steganography is not a security control nor is it best practice. The question is also not about how to be "hard to spot".
    – schroeder
    Commented Oct 5, 2018 at 9:23

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.

  • 4
    Email is not secure let alone anonymous emailer services. OP wants to securely exchange private keys. Commented Jul 24, 2016 at 17:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .