I have a couple of private keys that I use to administer Amazon EC2 instances.

I recently lost these keys when I did a re-install of my computer and I found out that the CD-RW I'd backed them up to was unreadable. So, I'm looking for a slightly more robust backup solution and I'm thinking about using something like Dropbox, because it uses SSL for confidentiality of transport and then my data is stored securely.

Is the risk I take backing up my keys on a service like this purely that the provider could screw up or be corrupt, or have I missed something else?

Update: The private keys have a pass phrase.

  • 7
    I'd encrypt the keys prior to shipping them to any third party, but that's just me. I'm not very trusting of infrastructure I don't support. Mar 13 '12 at 21:15
  • 1
    @EvanAnderson Of course, then you have to store the encryption keys somewhere.
    – ceejayoz
    Mar 13 '12 at 21:41
  • Brabster, these private keys are ordinarily stored encrypted to a passphrase known only to you, yes? Or are you asking us about the wisdom of storing unencrypted private keys on a cloud service?
    – MadHatter
    Mar 13 '12 at 21:42
  • @ceejayoz: I'm talking about encrypting them with a passphrase known only to me and storing that key in my head. Mar 13 '12 at 21:59
  • Yes, using a pass phrase on my keys.
    – brabster
    Mar 14 '12 at 21:46

There's also the whole "Dropbox can read your stuff" problem.

What you should do is encrypt everything before putting it into Dropbox. Use something like KeePass as a secrets vault. Put a good password on it. KeePass will encrypt locally, before putting your stuff into Dropbox. You will then use KeePass on other computers to access those secrets.

Take a look at:


So, in summary, encrypt locally. Use Dropbox to sync those encrypted files.

  • 1
    But that gets you into a chicken-and-egg problem; the private keys you encrypt have themselves to be encrypted to a private key. Where do you keep copies of that private key?
    – MadHatter
    Mar 13 '12 at 21:30
  • 2
    You keep the master password in your head. Maybe also on a slip of paper in a bank vault if you get hit by a bus, and your wife needs to open the files.
    – cjc
    Mar 13 '12 at 21:30
  • Unless I'm gravely mistaken, very few things that offer decent encryption actually encrypt to a passphrase; few human beings can reliably remember passphrases with enough entropy. Instead, they create nonce keys, encrypt to those, and store the encrypted nonce key under the passphrase. That given, where do you keep that nonce key?
    – MadHatter
    Mar 13 '12 at 21:32
  • Well, the discussion of the KeePass's key derivation is at keepass.info/help/base/security.html#seckeyhash and my passphrase is 30+ characters long. Yes, the passphrase has less entropy than a properly generated encryption key, but I believe it's more than sufficient for this purpose.
    – cjc
    Mar 13 '12 at 21:36
  • And that's a fair enough belief. But if you hold it, then where's the harm in uploading encrypted private keys to the cloud as-is, as the original poster proposed to do?
    – MadHatter
    Mar 13 '12 at 21:40

If you have a private key you wish to keep safe (I'll call it Key A, which could also be a collection of private keys tarred together into one file to keep safe), create another public/private key pair (Key B).

Securely copy Key B around to multiple computers that you trust. This can be done by creating a temporary public/private key pair (Key C) on the destination computer, transfer the Public Key C to the original computer, encrypt Private Key B with Public Key C, and transfer the encrypted file back to the destination computer where Private Key C can decrypt it.

With Private Key B on several machines you trust, encrypt Private Key A with Public Key B, and place that file in secure storage (could be on a location you don't trust, like Dropbox).

So, then if ever Key A gets lost/corrupted on your local workstation, it's an easy/quick restore to grab the Key-B-encrypted-Key-A file from Dropbox and decrypt it to restore.

If Key B gets lost/corrupted, you still have Key A, so you could just create a new Key D to replace Key B and do the setup again, or go grab a copy of Key B off one of the other computers you trust you made copies of it on.

If your whole computer is lost (you lose Key A and Key B at the same time), you will need to go to one of the other computers with Key B on it and grab the Key-B-encrypted-Key-A file from Dropbox and decrypt it to restore Key A.

So, this plan allows Key A to be kept safe using traditional backup options copying the file to many (possibly untrusted) locations, which opens up offsite, offshore, and off-planet options. It also means Key A can be restored quickly if need be, as the Key-B-encrypted-Key-A file can be passed around untrusted, so can be attached to emails or whatnot.

It keeps Key B safe by being on multiple trusted locations. This being ServerFault and not SuperUser, we're likely talking in a corporate setting, so hopefully the corporation has local servers and co-located servers they trust that can host such things. In addition to live, running servers, copies of Key B can be put on offline storage (tape backups, archival CD, etc.) in a bank vault or similar. Restoring Key B then becomes a slower process as you may have to visit the bank vault to go get a copy, and you should be checking those offline backups periodically, so you can catch the situation like the original post where the CD went bad.

  • "With Private Key B on several machines you trust" if you have safe places to keep copies of a private key, you don't have the original problem, which is about how to safely keep distributed copies of private keys.
    – MadHatter
    Mar 1 '16 at 14:42
  • True, you could just keep Key A in those locations. But then with the same trade-offs: slower turnaround time to restore, and possibly increased risk of losing all copies at once if not done well. Mar 1 '16 at 15:01
  • The latter applies equally to key B. And why it is slower to restore by directly getting key A, than by getting key B from the same places then using that to decrypt a local copy of key A?
    – MadHatter
    Mar 1 '16 at 15:32
  • "the latter" meaning "losing all copies at once"? In this scheme, the encrypted Key A can be stored in an untrusted location, which everyone has inherently more of than trusted locations. Therefore the risk of losing all the encrypted Key A copies is less. In a typical restore setting, yes, speed would be the same if you have a local copy of Key B. However, in the situation of losing a whole computer, driving to the bank to get a copy of Key B out of the vault is slower than going to any working computer and logging into Dropbox to get another copy of the encrypted Key A. Mar 1 '16 at 15:39
  • I don't particularly want to get into a lengthy discussion on alternatives to a four-year-old question with an accepted, upvoted answer, so perhaps I should leave it at "I am unsatisfied with your answer".
    – MadHatter
    Mar 1 '16 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.