# Using the same private key to generate Schnorr and BLS signatures

I am wondering if it is possible or if there are any limitations to using the same private key to generate Schnorr and BLS signatures. Specifically, assuming I have a private key $x$, I want to use it to sing some messages using Schnorr signature scheme and other messages using BLS signature scheme. The verifier should be able to tell that the signatures were generated with the same private key.

One way I can think of is to have a single public key $X$ on a curve $g$ and use it for both types of signatures. This probably limits the selection of $g$ to the curves that support BLS scheme (e.g. BLS12-381). But I'm not sure if there are any drawback to using Schnorr signatures on these types of curves.

• What's the point? Why not just use two keys and treat the pair of resulting public keys as the full public key? – otus Sep 8 '18 at 7:33
• This is for cryptocurrency protocol I'm working on. Each account is defined by a single private key. The owner of the account sometimes needs to sign messages using Schnorr scheme, and other times using BLS scheme. People receiving these messages should be able to tell that they were signed by the same user (owner of the private key). – irakliy Sep 8 '18 at 16:45
• Still, if you define both the private and the public key as pairs of keys on those two systems, you get the same effect as if they were single keys shared on the two systems. The receiver can use the public key part that corresponds to the private key part. (Not that this might not be a theoretically interesting question nonetheless.) – otus Sep 8 '18 at 17:22

There is a classic solution, applicable to any two public-key cryptosystems: deriving both private keys from a master key, which plays the role of a new common private key.

Start from a master key. Derive from it and two public constants the seeds of the CSPRNGs used for the key generators of the two public-key cryptosystems (use some Key Derivation Function like HKDF). Perform the two key generations (limited to public key if that help), to obtain the public keys. And, at each use of the master private key for one cryptosystem, perform the appropriate one of these two derivations, then the appropriate key generation (limited to private key if that helps), thus obtaining the private key for the cryptosystems, and use it as normal.

The main drawback is more complex/costly use of the private key, and that's an issue with RSA. But for Discrete Logarithm based cryptography, including Elliptic Curve Cryptography, the overhead tends to be minimal (relative to private key use), because the KDF has comparatively low cost, and reducing its output to a private key is usually essentially modular reduction (ECDSA) or bit extraction (Ed25519).

Note per comment: the requirement that "the verifier should be able to tell that the signatures were generated with the same private key" is met only as far as the verifier is certain that the two public keys used to verify the two signed messages have been generated from the same master key. The person preparing the public keys must thus be trusted. To avoid errors, it is possible to add a unique common identifier to the public keys. That can be obtained from the master key by derivation with another constant.

• Thank you! One thing I didn't quite understand: how would a person seeing two messages signed with different keys derived from the same private key be able to tell that both messages were signed by the same user? – irakliy Sep 9 '18 at 21:47

What you're doing is pointless. Using identical public keys in two different schemes means that anyone who breaks EITHER scheme gets your private key (and thus breaks both schemes at once). This is bad security design. You want to strengthen your weakest link, not add more links.

If you need to sign messages in two different ways it's much easier and safer to just add a bit to each message indicating what kind of message you're signing.

• I understand that this is another limitation. However, before deciding whether to use this approach or not I'd like to understand if there are any other limitations. – irakliy Sep 9 '18 at 1:31