2
$\begingroup$

I have an RSA private key (more specifically, an SSH key in Putty format, 4096bit) and want to use its SHA256 hash as an AES256 key, instead of using an independent newly generated AES key.

Are there any reasons why doing this might be a (very) bad idea?

In terms of entropy etc., it should be still sufficiently secure for real life (I think?). But are there any pitfalls, like certain properties of good RSA keys that would make the AES key much worse / easy to break (than one directly made by a properly used CSPRNG)?

Both keys are meant to protect the same thing, ie. if an attacker can get one, deriving the other doesn't make the situation worse.

(This not not an XY problem. And I know that this is not the usual use case.)

Improve this question
$\endgroup$
1
  • $\begingroup$ The usual approach is to derive a random AES key, and encrypt it with the RSA key (using proper padding such as OAEP or OAEP+). Then store the encrypted key along with the message. You could also use a hash. I would suggest using HKDF with a random salt and the RSA key as secret, if you choose to go this route. Then store the salt in the clear, alongside the ciphertext. You would still be better off using something like GPG though. $\endgroup$
    – Demi
    Apr 22, 2016 at 22:14

1 Answer 1

Reset to default
4
$\begingroup$

First of all, the usual way to do this is to generate a new random AES key and then wrap it with the public key. Generally you don't encrypt with the private key at all.

Yes, SHA-256 is a one way hash so you can do this. The problem is that you would still need to encrypt with a public key to let the other party know the AES key (unless you use the key to encrypt for yourself, of course).

There are however a few pitfalls:

  • the private key needs to be encoded as bytes, and not all encodings are canonical; i.e. you could use different encodings for the same private key. If this ever happens in your scheme you would not be able to generate the same AES key;
  • you'd need a separate input - e.g. a counter (nonce) - if you want to generate more keys;
  • SHA-256 is not a KDF, you could use HKDF instead (which just requires a hash function to work).
  • Sometimes hashes over private keys are used as key identifiers. You must make sure that this is not the case. For RSA however the key identifier is usually generated by a hash just over the public modulus.
  • You'd forgo the option to store the private key within a security module, as direct access to the components that make up the private key would likely not be available.

The biggest question that you should ask yourself is this: why do you need an AES key for encryption at the location of the private key. That's a strange use case.

Improve this answer
$\endgroup$
2
  • $\begingroup$ That's a strange use case. I know :) ... Thank you for answering (upvoted). So aside from usage problems (use case, encoding stuff etc.), you see no real reason why such an AES key should be somehow easier to crack? (as in, real-life easier, not just "half as much million years" etc.) $\endgroup$
    – deviantfan
    Apr 22, 2016 at 23:57
  • 1
    $\begingroup$ Not really no. Leaking the private key would do the trick. $\endgroup$
    – Maarten Bodewes ♦
    Apr 23, 2016 at 0:00

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.