8
$\begingroup$

What is the harm if I publish an encrypted RSA private key publicly? Or in this case, what is the harm if I publish many thousands or millions of them?

Assuming that the private key is encrypted with a typical user password, the passphrase is some combination of password + user ID (which is not necessarily user-selected), some method of key stretching is used, and that it's not obvious what the key is used for, is there any harm?

The reason I ask is because I am wanting to investigate a way to store public and private keys on behalf of web users for use within a web browser. The private key would be stored at an HTTPS URL that does not describe the user that owns it nor describes what the key would access. The data stored at the private key URL would be read-only.

The intention is to assume that any private keystore would be eventually attractive enough to be attacked and breached and therefore assuming that keeping the private key files hidden or protected would be poor or insufficient security.

The fact that this private keystore exists would not be treated as private information. All keys would be accessible by anyone that knows the URL for each. There would be no key/directory index provided. The key files may be stored on simple file storage/hosting systems like Amazon S3, but they would always be served over HTTPS.

Please ignore the issue of possible theft of password via keylogging and ignore the issue of possible theft of unencrypted key via direct JavaScript access.

Improve this question
$\endgroup$
5
  • 3
    $\begingroup$ The assumption of a good password is pretty problematic. Even with strengthening techniques applied, a password should have 60 bits of entropy or more. Very few users will use a password that's so strong. And even with 60 bits(+10 to 20 bits for strengthening) it's one of the weakest cryptographic parts in an application. $\endgroup$
    – CodesInChaos
    May 25, 2012 at 10:31
  • $\begingroup$ My present understanding is that the only way into the key is via brute forcing. Also, I suggest that this is more secure than a database of password hashes. Unless someone can break into S3 or get the S3 account privileges, no one can list the keys on the server but have to know the URL in order to download a single key, which I suggest is no more security-by-obscurity than a password. $\endgroup$
    – Emmaly
    May 25, 2012 at 19:14
  • 1
    $\begingroup$ @DustyWilson, CodesInChaos's point remains valid. Given what we know about how users choose passwords, your proposed method is probably not very safe. (P.S. I don't understand why you think this is more secure than publishing a list of password hashes in the same location as you are currently publishing the password-encrypted private keys. Seems roughly comparable to me: neither one is very secure.) $\endgroup$
    – D.W.
    Sep 8, 2012 at 7:40
  • $\begingroup$ The only difference is that I'm actually using the public keys, not just verifying a shared secret. Without access to the underlying filesystem or some sort of sniffing, you can't know the full URL without knowing the user ID and the user passphrase. One could brute force their way to find a key, but doing so would be no less difficult than if they were brute forcing a typical login form. I would like to hear more specifics about the bits-of-entropy topic with regard to this particular question. $\endgroup$
    – Emmaly
    Sep 8, 2012 at 7:55
  • $\begingroup$ I edited the question a little bit to be more accurate with what it is I'm wishing to do. In this particular use case, it seems that if this described situation is insufficient, I would not be confident in storing the user keys. $\endgroup$
    – Emmaly
    Sep 8, 2012 at 8:05

1 Answer 1

Reset to default
5
$\begingroup$

Systems like ssh, for example, often encrypt a user's private key using a password, so that is not new. The fact that they are published on a web server that technically anyone could access is a little different. But, if the password is strong, brute force and dictionary attacks would be impossible. So the system seems secure.

That if, though, is a big if. As CodesInChaos points out, users are bad at picking good passwords. So, lets assume they are still bad at picking passwords. Eventually the URLs will become known, so we can't rely on that for security. An attacker can then download the encrypted private keys and decrypt them since a bad password was chosen.

How does this differ from traditional passwords? Well, in traditional passwords, at least the database and server can be hardened to keep people from getting material that can be used in an offline dictionary attack. Under this system, the URL scheme would be the only thing preventing an offline dictionary attack.

Improve this answer
$\endgroup$
1
  • $\begingroup$ None of that sounds like new info, but it certainly is valuable nonetheless and is appreciated. One of the important details is that the passphrase on the key would be hardened via some key stretching mechanism in order to make local brute force attempts extremely expensive. The keys would, hopefully, be rotated frequently enough such that it would be unlikely that a key could be brute-forced successfully while it's still a usable key. Thanks for your response on this; it's appreciated. $\endgroup$
    – Emmaly
    Sep 7, 2012 at 20:57

Your Answer

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

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