# Private RSA key for HMAC key

I am creating software tokens for future request authentication, and I want to use an HMAC for the token to make them tamper-resistant. To ensure I can check the HMAC later I need a secret, persistent key. Is there a security concern in using a private RSA key as the HMAC key? If not, what would the best values be from the key? This link says:

The security of RSA derives from the fact that, given the public key { e, n }, it is computationally infeasible to calculate d, either directly or by factoring n into p and q. Therefore, any part of the key related to d, p, or q must be kept secret.

I would expect it to be the private exponent (D) then, but I am not sure if some other combination of values would offer strong security (like P,Q, and D concatenated).

Edit: clarification

The reason I am asking about the RSA private key is the HMAC key needs to be stored so that the HMAC can be validated by the server on future requests. An RSA private key is an easy to manage, persistent value. I am not using the public key, or performing any aspect of public key crypto. I need a way to securely manage the HMAC key, and I am wondering if there are any good reasons not to use an RSA Private Key for this purpose.

• Would the RSA "public" key also be kept secret? $\;$ – user991 Apr 2 '14 at 23:00
• Effectively. The Certificate will be on the server, but it will not be used for anything else. – Kyeotic Apr 2 '14 at 23:03
• The Certificate is not important for my question. $\:$ Whether or not the public key will be used for anything else is also not important for my question $\:$ Would the RSA "public" key be known to anyone else? $\hspace{.48 in}$ – user991 Apr 2 '14 at 23:09
• I realize I'm not answering your question, but I am not sure what I am missing. Is there some other way to know the public key than to look at the certificate? I believe the answer to your question is no, nobody else know's the public key. – Kyeotic Apr 2 '14 at 23:11
• Why not simply use a symmetric key? Also, the RSA public exponent isn't directly suitable use for an HMAC key, since an HMAC key needs to be something like 256 bits (e.g., for SHA-256) whereas $d$ will be around 4,096 bits. – Stephen Touset Apr 2 '14 at 23:12

If you truly can't be dissuaded from 'using' an RSA key for HMAC, be sure to derive a strong symmetric key using HKDF with a salt and some associated data.

I have a suggestion for you based on your comment to Stephen's answer. If all you need to do is store the symmetric key in the key/cert store, why not encode some generated symmetric key in the format (PEM/ASN.1/DER/etc.) expected by the cert store and use application-layer code to read it in and use it as an HMAC key? You could even use some junk data/padding if there's a length problem.

EDIT in response to comment: I mean use the RSA private key as the input to a key derivation function like HKDF.

• I don't want to give the impression that I can't be dissuaded, it's just that all the negative responses have lacked a reason that its a bad idea. "Not for that purpose" isn't a reason not to do it. I'm not sure what the first part of your answer means. Do you mean the HMAC should produce a symmetric key, or that the RSA key should be a HKDF key? – Kyeotic Apr 3 '14 at 1:05
• A reason not to do it would be something like: the HMAC product of an RSA Key would make it possible to derive the RSA Key, or the HMAC product of [Some other source] is harder to crack. Something that makes some other method better, instead of just more common. – Kyeotic Apr 3 '14 at 1:07
• RSA private exponents are not uniformly distributed, which means the security arguments $\hspace{.92 in}$ for HMAC would not apply to using those as keys. $\;$ – user991 Apr 3 '14 at 1:23
• I'm not sure what you mean by that. What security arguments? – Kyeotic Apr 3 '14 at 1:50
• What sort of attack is somewhat beyond the point. The problem is that the security proof no longer holds. Without a security proof involving non-uniform keys, the best we can say is that the security is undefined. – Stephen Touset Apr 3 '14 at 6:23

The reason I am asking about the RSA private key is the HMAC key needs to be stored so that the HMAC can be validated by the server on future requests. An RSA private key is an easy to manage, persistent value.

You seem to be under the misguided and mistaken belief that an RSA key is somehow easier to manage and persist than a symmetric key.

I am wondering if there are any good reasons not to use an RSA Private Key for this purpose.

RSA private keys were not designed or intended for this purpose, and there seems to be no legitimate reason why you would actually want to do it. Use primitives for the purposes they were designed. Don't try to be clever. And don't invent your own crypto.

• I am definitely under the belief that RSA keys are easier to manage. What methods would you recommend for securing a symmetric key that make it easier? – Kyeotic Apr 2 '14 at 23:29
• Let me flip the question around. By what mechanism do you intend to "secure" your RSA key, and why does that mechanism not apply to a symmetric key? Keep in mind that the former is a 256-byte or 512-byte string, and the latter is a 16-byte or 32-byte string. – Stephen Touset Apr 2 '14 at 23:32
• The RSA key will be in the server's certificate store, which is secured by the OS's user system. I don't know of a way to put a symmetric key there, so it would have to be in either a file or a database. It would have to be a file not part of the app deployment, which in my opinion makes it harder to manage. Putting in the database doesn't result in any more permission work (since the app account needs to access the cert, too), but it means either the DB schema has to not touch it, or it has to go in its own database. All of those options are more work than the standard certificate store. – Kyeotic Apr 2 '14 at 23:37
• What operating system? As Rick states in another comment, at the very worst, you could encode a symmetric secret into an PEM/ASN.1/DER file and store it in the certificate store. – Stephen Touset Apr 3 '14 at 6:22
• Windows. I am not opposed to doing that, though I will have to figure out how. – Kyeotic Apr 3 '14 at 6:34