![]() ![]() (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. 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: But there may be some times when that's not practical for some reason (or, more likely) it's not your call to make. You should minimize these times as much as you can, preferably by just walking the client that needs them through generating the keys themselves. ![]() 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. The best way to securely send private keys is to never send them in the first place. You still have to exchange information on the public keys, for example the fingerprint, through a pre-established, trusted channel like described above.įirst, read what Deer Hunter wrote above. 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. 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. What method to actually use completely depends on your needs, and potential eve-droppers. ![]() sending an encrypted mail, while transmitting the passphrase through another channel (phone, text messate).secure upload to a trusted machine, for example using SSH.traveling in person, if necessary comparing official IDs.sending them using (snail) mail, sealed if necessary.sending encrypted mails to an address you already have trusted public keys for, no matter whether OpenPGP or S/MIME.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).ĮDIT: For the stated use case of private keys for a hosting provider, you are still better off generating them in place.įor 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.ĭepending on your needs and the possibilities available, this might include Sending the keys means the people at the other end of the channel must trust you and you must trust them.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. If you don't have secure shell access (SSH) to the target device, you generally cannot securely copy (SCP) the files.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). 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. 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).If you have shell access to the server they are used at, you simply generate them in situ.You can secure private keys by not transmitting them at all. TL DR: private keys are called private for a reason.
0 Comments
Leave a Reply. |