Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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!

share|improve this question

migrated from security.stackexchange.com Jul 20 '12 at 11:17

This question came from our site for Information security professionals.

    
Why bother? Just generate a completely independent random key and encrypt it with the private key. –  Polynomial Jul 20 '12 at 8:39
add comment

1 Answer 1

up vote 4 down vote accepted

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

share|improve this answer
    
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? –  aspergillusOryzae Jul 31 '12 at 23:15
    
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. –  Ilmari Karonen Jul 31 '12 at 23:39
    
Ah, good point. Thanks! –  aspergillusOryzae Aug 1 '12 at 0:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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