5
$\begingroup$

I realize this is mixing the purposes between asymmetric and symmetric crypto, but I was wondering if it is safe to use a hashed, truncated private key (asymmetric) as the symmetric key for encrypting data at rest? For this question I am presuming RSA is a 1024 bit key, SHA1 produces 160 bits, and AES is using a 128 bit key.

  • It appears that the data obtained from an RSA private key maintains a specific structure and is not completely random, so simply taking the first 128 bits from the private key would not provide enough entropy for a symmetric key, correct? (I previously heard that truncating a randomly generated number is okay when selecting symmetric keys - but in this case all the data within the private key is not random)
  • By hashing the entire RSA private key, the result is condensed into 160 bits, more usable with AES 128 key size, but are we greatly reducing the entropy by doing so? (Of course you could use SHA2 for AES 256, etc)
  • Would it be recommended to extract something like the algorithm components instead like p and/or q since those values are 'more' random?
  • Any other suggestions?

Thanks in advance!

Improve this question
$\endgroup$
1
  • $\begingroup$ Why bother? Just generate a completely independent random key and encrypt it with the private key. $\endgroup$
    – Polynomial
    Jul 20, 2012 at 8:39

1 Answer 1

Reset to default
6
$\begingroup$

I see no reason why that wouldn't be secure. If you want to be sure, though, you could use a standard key derivation function such as HKDF or PBKDF2 to derive the symmetric key from the RSA key.

These functions are primarily designed for deriving encryption keys from low entropy-per-byte sources such as passphrases, but there's no reason why you couldn't use an RSA key as the "passphrase". In any case, what they're designed to accomplish is to distill the entropy from a long but not entirely random input down into a pseudorandom output suitable for use e.g. as a symmetric encryption key.

(Many KDFs also include features such as adjustable work factor parameters for key stretching, useful for slowing down brute force attacks on low entropy passphrases. However, for your application, you may safely choose a KDF without such features, or just set the parameters for maximum performance.)

Improve this answer
$\endgroup$
2
  • $\begingroup$ In the instance of PBKDF do you think it would be okay to use the first X bytes (recommended more than 64 bits), so say something like the first 64 bytes (instead of bits) as the salt and the rest of the 1024 or so bit RSA key as the 'password' for PBKDF? Do you think the first 64 bytes wouldn't contain enough random information if the data represented a private key struct that had a little bit of header information in the first 8-10 bytes? $\endgroup$
    – aspergillusOryzae
    Jul 31, 2012 at 23:15
  • $\begingroup$ I'd suggest just using the entire key as the "password" and leaving the "salt" parameter empty (unless, of course, you can include an actual salt along with your encrypted data). In any case, it should not matter much: both the password and the salt parameters are ultimately hashed together. $\endgroup$
    – Ilmari Karonen
    Jul 31, 2012 at 23:39

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.