Score:4

Can a digital signature be used to generate a key for AES encryption?

gf flag
cjd

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

poncho avatar
my flag
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?
Maarten Bodewes avatar
in flag
@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.
Maarten Bodewes avatar
in flag
I think the question comes down to: can signature generation be used as a key derivation function (KDF).
poncho avatar
my flag
@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
Maarten Bodewes avatar
in flag
@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.
cjd avatar
gf flag
cjd
@poncho so no. The only person who will ever decrypt the data will be the user who originally encrypted it and owns the private key. So is that okay?
cjd avatar
gf flag
cjd
@MaartenBodewes the key will still be derived by scryprt function. But the signature is used as the secret password to general the key.
Maarten Bodewes avatar
in flag
I've seen that in action for an RSA signature generation function using PKCS#1 v1.5 padding. That in itself doesn't mean that it is secure of course ;) The bad: if you want to patent your scheme you're 20 years late at the very least...
Score:3
in flag

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.

cjd avatar
gf flag
cjd
That is great! Really appreciate the detailed answer. Thank you.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.