I'm curious about exploring uses for a distributing a single RSA private key with a passphrase instead of trying to secure the private key and distribute the public key. With the private key (and passphrase) the public key could be created as needed.

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 whole 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.

What is the purpose of distributing an RSA private key? Why can't multiple hosts have their own keypair?
–
Stephen TousetMar 28 '13 at 16:48

The entity to which the private key belongs cannot store it themselves and must use a/multiple 3rd parties to store it.
–
XeoncrossMar 28 '13 at 16:50

Will the RSA key be unlocked and used on those machines? Or will it be transferred to a controlled environment first?
–
Stephen TousetMar 28 '13 at 16:54

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.
–
XeoncrossMar 28 '13 at 17:02

1

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).
–
XeoncrossMar 28 '13 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.

@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.
–
ponchoMar 28 '13 at 20:45

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.

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.
–
XeoncrossMar 28 '13 at 20:52

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.
–
Stephen TousetMar 28 '13 at 21:13

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.
–
John DetersMar 28 '13 at 22:32