Generating a key pair using a signature generated by an existing key I’ve built an app in which each user has a private/public key pair and I want to generate a second one for them, however I cannot store the second private key anywhere. 

What would be the drawbacks of deterministically generating the second private key from static information signed by the first one, compared to generating it randomly? I could generate it again each time a user opens the app but is it safe?

This is in the context of a web app on Ethereum, which uses deterministic ECDSA.
Several issues with the proposition of generating a derived private/public key pair as (or from) a signature computed with a master private key.


Not all signature schemes are deterministic, thus what's proposed might end up not allowing reproduction of the derived key.
We would need to discriminate the particular message input to the signature scheme used to generate the derived key, and ensure that an adversary can not obtain the signature of that message with the master key, thus ruining the confidentiality of the derived key.
For arbitrary signature scheme, we could imagine some security issue where signatures (past and future) with the master key weaken signatures with the derived key.


A more conservative option is to use the master private key itself as the key input of a symmetric Key Derivation Function (unrelated to the signature scheme), which output is (or is used to deterministically generate) the derived key. This can be generalized to any number of derived keys, using an auxiliary input of the KDF for a derived key type or index. That option assumes that the master private key is not in a box/HSM/Smart Card/enclave restricting its use to signature, and that a strict policy to the same effect is not in force (which is common, e.g. by reference to FIPS&nbsp;186-4).



Update: a comment mentions that the master private key is not directly accessible (making the above conservative option impossible); and a deterministic (variant of) ECDSA.

If we can reserve a message $C_D$ (solving 2.), post-processing as$$\text{DK}\gets(H(\text{Sign}_\text{MK}(C_D))\bmod(n–1))+1$$seems to be good way to derive a private key $\text{DK}$ from master private key $\text{MK}$, with $n$ the generator's order and $H$ a hash at least 64-bit as wide as $n$ is. The modular reduction and 64-bit limit is per FIPS&nbsp;186-4 apendix B.4.1. If $H$ is secure in the Random Oracle Model and as costly as a signature verification, then this is computationally secure (argument: an attack allows to forge the signature of $C_D$, or otherwise breaks the signature scheme, or the hash). It can only help to use a purposely slow KDF for $H$.

The above formula assumes ECDSA with only the signature TRNG changed to a deterministic PRF keyed by the private key. For EdDSA, we only need to hash the signature of the reserved message $C_D$ to the width of a private key, and condition that with the masking prescribed in EdDSA.

More generally, with a deterministic signature scheme, a reserved message, and a key generation procedure using a KDF independent of the signature scheme and at least as costly as signature verification, we are good to go.



Caveat: any key derivation should be performed in a safe environment, or otherwise guarded from side channels.