I need to store various private keys for my clients.

Given these options, what would be the least prone to brute force attacks:

  • Encrypt the private keys using a separate RSA key (each user get its own key), with its password set to a SHA-512 hash of the users password.
  • Store the private keys in a LUKS volume with its password set to a SHA-512 hash of the users password.

Additional considerations:

  • Salt the hash with the RSA key or a unique property of the LUKS volume.
  • 2
    If a second party (you, in this case) has access to the private key of an RSA key pair, then the crypto involved is security theatre. You should go back to the drawing board and consider other ways of accomplishing what you're trying to do. – Bob Brown Feb 14 '15 at 15:44
  • Thank you for commenting, Bob. I don't understand why it would be superficial. Aren't password-protected RSA private keys protected with AES encryption? And a hex representation of a SHA-512 has an entropy of about 400. – Cochise Ruhulessin Feb 14 '15 at 15:53
  • Because you might be subject to legal process, hackable, or generally untrustworthy. I could not tell from the question whether you are able to decrypt the private key. If so, security theatre. If not, then you are acting as a key escrow service. That might be OK, but it's not something I'd want to take on. – Bob Brown Feb 14 '15 at 15:56
  • Separately, one iteration of SHA-512 is unsuitable for deriving an encryption key from a password. You are incorrect to assume "a hex representation of SHA-512 has entropy of 400." Applying SHA-512 (or any hash) cannot increase the entropy past the entropy of the password; if you feed a password with 20 bits of entropy in, you'll get a hash with 20 bits of entropy out. The actual thing you want is a slow hash, because (given that you can't increase entropy) your only way to make attacks infeasible is to make it so checking each hash takes some time, so as to slow the brute-force. – cpast Feb 14 '15 at 16:08
  • As a general rule you should always take a look at the 'bad apple' approach. Assume you have an admin on your staff who has full access to all of your systems, source code, databases, physical hardware, everything. And malicious intent, Now work on trying to design a system where they cannot access any sensitive customer information. Encryption becomes moot if you can sniff the password ( even out of ram or packet sniffing ) – Damian Nikodem Feb 18 '15 at 17:47

Your Answer

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

Browse other questions tagged or ask your own question.