The owner of the RSA key can't store the key, so they need to hand the key to an untrusted entity for storage. Before they hand it over they encrypt it using AES with a multi-word phrase they can remember.

The idea is that I could generate a private key and store it outside the entity in a non-secure location but not worry (as much) about it since it is protected by a passphrase.

The private key might be stored in several places - in fact and I have to assume they are all publicly-accessible (like a web page). But when the entity wants to do something with the key it requests it back from the storage places and then (with the users password) decrypts it and uses it for what is needed.

  • 2
    $\begingroup$ What is the purpose of distributing an RSA private key? Why can't multiple hosts have their own keypair? $\endgroup$ Mar 28, 2013 at 16:48
  • $\begingroup$ The entity to which the private key belongs cannot store it themselves and must use a/multiple 3rd parties to store it. $\endgroup$
    – Xeoncross
    Mar 28, 2013 at 16:50
  • $\begingroup$ Will the RSA key be unlocked and used on those machines? Or will it be transferred to a controlled environment first? $\endgroup$ Mar 28, 2013 at 16:54
  • $\begingroup$ The RSA key will be returned to the owning party when it's needed which will then use it to do what it needs done. The problem is that the owning party can't store the key. $\endgroup$
    – Xeoncross
    Mar 28, 2013 at 17:02
  • 1
    $\begingroup$ They don't, the physical user of the owning entity must remember it. (If they could remember the RSA key the problem would be solved right there). $\endgroup$
    – Xeoncross
    Mar 28, 2013 at 18:32

2 Answers 2


Based on skimming the relevant RFCs, I can't find any outright problems. Key derivation from the password is performed via PBKDF2, and best I can tell, the choice of cipher is left up to the implementation. As long as a good cipher is chosen, a truly random 30-character passphrase consisting of uppercase letters, lowercase letters, and digits should have roughly 178 bits of entropy. This is significantly higher than that of a 128-bit key, which is considered to be secure.

It still gives me a bad feeling that I can't shake. But as long as keys are only ever decrypted on trusted devices, I can't personally find a reason why it would be unsafe.

Not that this should be considered an endorsement by any stretch of the imagination.

  • 1
    $\begingroup$ @Xeoncross: of course, the above is entirely dependent on the passphrase being random (or mostly); if the 30 character passphrase is "abcdefghijklmnopqrstuvwxyz1234", then all bets are off. $\endgroup$
    – poncho
    Mar 28, 2013 at 20:45

So, you have several requirements.

  1. Multiple parties share ownership of a part of the key.
  2. Parties will use human memory to store their parts.
  3. The passphrase must be a minimum of 30 characters.

The first requirement definitely sounds like a job for Shamir's Secret Sharing algorithm, where you have to bring together at least $m$ of $n$ shares in order to recover the original secret.

The second sounds like a need for a strong password hashing algorithm.

The third simply requires a compliance policy on passwords.

All together, it sounds like you are trying to recreate a Key Ceremony, for which standards and practices already exist. Perhaps it would be better to start there than to rebuild it all from scratch, as you could easily make a mistake in a home-grown plan. This is especially true if the practice will be externally audited, as auditors (like PCI assessors or SOX auditors) love to see organizations using standards for these activities.

  • $\begingroup$ Actually, multiple parties can have a whole copy of the key. There is no sharding/splitting of the key and the only thing remembered is by the original human is the passphrase - the private key is stored somewhere out in the public. $\endgroup$
    – Xeoncross
    Mar 28, 2013 at 20:52
  • $\begingroup$ I believe @JohnDeters' point is that your problem is equivalent to a secret sharing scheme with $m = n = 2$. Data derived from the passphrase would constitute one of the two shares, and each server would possess the single remaining share needed to reconstruct the key. $\endgroup$ Mar 28, 2013 at 21:13
  • $\begingroup$ Yes, in the case of each person having full ownership of the key, SSS would still work, but so would individual asymmetric encryption of the key. I'd still recommend SSS; key splitting is recommended for master root key applications, and it sounds like you have a circle of people who have a strong interest in the key. Allowing any single entity the opportunity to turn rogue and "rule them all" is a risky practice. $\endgroup$ Mar 28, 2013 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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