I am looking to see if using a digital signature is a secure and reasonable way to generate a key for AES encryption.

To flow would be as follows:

A user signs a message m with their private key. They actually sign the hash of m but this is taken care of as part of the digital signature creation function. This returns the digital signature s.

Provided s remains secret, is s a secure digest to use in order to create a key k for AES.

They key k will be created as follows:

const crypto = require('crypto');

crypto.scrypt(s, 'unique-salt', keyLength, (err, key) => {
    console.log(key.toString('hex')); // 12dd454fb...

Where the first parameter of the function s is the digital signature created by the user.

The documentation for the Node crypto package doesn't specific any requirements for this parameter.

I understand that if the digital signature is obtained by someone else then that person can decrypt and encrypt messages, however the same can be said if that person obtains whatever string is used as that parameter.

So the two questions are:

  1. Is this a secure and suitable way to generate a key for AES? Assuming that digital signatures are unique and difficult to guess by people who do not have access to the private key. And assuming that the digital signature used to create the key is kept private.

  2. Is the security dependent on the message m that is signed? Does this need to be kept secret also? My assumption is that is does not matter the what the message is as even if mallet knows this message they cannot create the correct digital signature as they do not have the private key.

Thank you

  • 1
    $\begingroup$ Will you need to share that AES key with someone who doesn't know the signature private key (or the signature system is nondeterministic - that is, the signature generated varies each time you generate it, even for the same message)? If you do, and you have an appropriate secure transport, would the alternative solution of just picking a completely random AES key work? $\endgroup$
    – poncho
    Apr 1, 2022 at 12:38
  • $\begingroup$ @poncho For (EC)DSA I guess you have the random $r$ that can be publicly shared. Similarly, you could share a seed or the random generated for RSA-PSS, kind of as a salt for a KDF. So I'm not sure that a deterministic function is a requirement, only that you can find an implementation that lets you inject the random values. $\endgroup$
    – Maarten Bodewes
    Apr 1, 2022 at 12:55
  • $\begingroup$ I think the question comes down to: can signature generation be used as a key derivation function (KDF). $\endgroup$
    – Maarten Bodewes
    Apr 1, 2022 at 12:59
  • $\begingroup$ @MaartenBodewes: for (EC)DSA, publishing two different signatures with the same $r$ is a BAD idea; I'd stay away from that. On the other hand, there are safe deterministic versions of (EC)DSA $\endgroup$
    – poncho
    Apr 1, 2022 at 13:49
  • $\begingroup$ @poncho I'm not suggesting that. I'm saying that you could use a random value for a single signature / key derivation and then take the $r$ (sorry, probably $k$) to generate the same value using the private key and the same message. Obviously you should keep the value of $s$ confidential if the message can change (that was the idea all along if I'm not mistaken). But once you have the symmetric key you could use a MAC value anyway to make sure that both sides have the same key. $\endgroup$
    – Maarten Bodewes
    Apr 1, 2022 at 15:06

1 Answer 1


Yes, you can use that. By definition an attacker should not be able to come up with a signature over any specific message without the private key. So if that's the case then a signature can indeed be used as a symmetric key, and I know of one instance where it was used like that (or at least as a secret, rather than a secret key).

However, you should be careful when doing so. Some signature algorithms are indeterministic, and that could complicate things. In the worst case it could make the signature algorithm entirely insecure. At best you might have to alter the signature generation routine to inject a seed or random value. It would also require you to store that the seed or random value, and that might go against your use case requirements. Note that if anything about the random number generation is changed - the algorithm, the extraction mechanism or the integer extraction - then you will likely get the wrong key (and yes, I've seen this happen).

However, if you'd use a deterministic version of RSA (PKCS#1 v1.5 padding) or deterministic ECDSA then you should be alright.

You are right to use a KDF after the data however. A symmetric key should extract all the randomness within the signature to be secure (possibly followed by key expansion to get to the right size, but that's commonly not required).

scrypt however is generally used on passwords. That's fine, but you probably don't need the salt or the work factor to stretch the key (as the amount of randomness in the signature should be high enough anyway). So it is fine if scrypt is required, but normally you'd rather use a KBKDF such as HKDF or just HKDF-Extract.

If you have access to the private key value you might as well use the KDF on that.

I'd definitely recommend that you'd use a signature generation algorithm that has at least the same strength as the symmetric key. Same goes for the KDF function of course; you can find details at keylength.com.

Furthermore, you might want to keep in mind that symmetric cryptography is hard to attack with a full fledged quantum computer, while asymmetric algorithms are not (although this scheme may be harder to attack than a generic signature generation scheme, depending on how it is used).

Yet another implementation note: signature generation functions don't expect that you keep the signature secret. For instance, a hardware module might be able to keep a normally derived symmetric key inside of the HSM. On the other hand, it might export a signature without fuss as a signature value is supposed to be public.

Side channel attacks on the signature value might also be possible, it is hard to tell in advance. So although this scheme should be theoretically sound, it is still highly inadvisable to do so unless there is no other way.

  • $\begingroup$ That is great! Really appreciate the detailed answer. Thank you. $\endgroup$
    – cjd
    Apr 2, 2022 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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