Derive a secret from an RSA private key

Question

What I want to do is deterministically derive a secure key from an RSA private key, such that the RSA private key cannot be derived from the secure key.

The first approach that came to mind was simply using the private key (or some fixed part of it) as the seed for a PRNG.

Since the output of AES is random, another idea is to use AES to generate the secure key, using the first 256 bits of the RSA private key as the AES key, and encrypting some known data.

Can anyone verify either approach, or otherwise suggest an alternative way to do this?

EDIT I left out the details of why I wanted to do this, to keep it focussed, but I guess it may be useful to know more:

I have an installer for a piece of server software that will run as part of a cluster. During installation, the installer will have access to a 'deployment' certificate - an X509 certificate that is used to sign certificates for each instance of the server (so, a CA certificate). Each server will also need to have access to a shared secret, which will be used to encrypt certain data that is shared between the servers (using AES). My thinking is that securely deriving this shared secret from the deployment certificate private key during installation is a low friction way to do it.

Answer 1

Unless you really want to actually "use" the RSA key in a mathematical way, you could actually just derive a password from it using a key derivation function (KDF) and using the certificate as a password...

There are two different kinds of KDFs: those you use when you have a poor entropy and are afraid of Dictionary Attacks (typically if you store humanly memorable passwords) like Argon2, and those that you use when you have a good entropy, which is the case if you rely on an RSA key. In the latter case, the HKDF is well suited for this.

The advantage of using HKDF is that you already have all the nifty feature you should otherwise implement:

• you have a Salt, so you can easily generate different keys, if one is compromised, for example.
• you have the notion of the label, so you can generate different keys for different usages.
• you have the size as a parameter, so you can easily plug in another encryption function in case AES gets broken, without changing the key generation algorithm.

Nonetheless, just hashing it would still be at least as hard as either:

1. finding your 'deployment' certificate
2. finding a preimage to that hash

And in case you worry, since an X509 certificate is certainly not a common password, it would require as much computation power to build a dictionary attack against it than to actually brute-force your certificate... (Which is hard.)

Note that 1. is true since we do not consider obscurity to be of any use, so you should assume that the attacker knows how you derive your secret key.

So in the end, if the "secret key" is compromised, finding the corresponding preimage (aka your certificate) of the cryptographically strong hash is hard for any cryptographic hash.

As hash, I personally like Blake2, since it can produce a digest of any size you may need for AES keys, is fast and is robust, plus it sports a Salt, so you can simply change that salt and keep going if a "secure key" is once compromised. But you could go with SHA-3 (aka SHAKE128 if you want 128 or 190 bits AES keys) and a custom salt you append to your certificate, too. Blake2X is also advertised as a KDF when you have a high entropy source.

Answer 2

I agree with @Lery, that using HKDF would be the best solution. You could use the d or p or q component of your private key (if you have direct access to them) as the IKM or salt value to ensure a deterministic derivation from your key.

If you do not want to do that or can't do because you do not have direct access to the key: RSA encryption/decryption can be used as a Pseudo Random Function (PRF) which can be used for a key derivation. Start with some value (shared secret, seed), and create a textbook-RSA signature for it. Preferably, you should feed that output into HKDF or at least SHA-256 afterwards.