This question is relevant for both crypto stack exchange and infosec stack exchange. I thought I'd ask here to get answers from a cryptography perspective.

If two systems use the same public key signature system, is it reasonable to re-use keypairs from one system on the other?

For example, both Matrix and the Solana blockchain use ED25519 keypairs.

Potential benefits of re-using keypairs would be:

  • reduction in key management, i.e. having a single secret key to store securely, shard, etc.

  • being able to re-use identities tied to existing public keys. Eg, to send Matrix messages to an address based on the public key matching a Solana wallet name. Or to send tokens to a Matrix user based on their matrix address. This would require additional support from user-facing software, but it would be possible to create such software.

Potential downsides:

  • I considered keypair collisions between the two systems, but this would seem extremely remote. Just as remote as randomly creating a new keypair in a single system that happens to match an existing keypair.
  • I haven't heard of this done in the past, especially in the many decades of 2048-bit RSA being very popular. Which makes me consider that I might be missing something. Has this been done before?

Is it reasonable to re-use a keypair across multiple systems that support the same signature system?


2 Answers 2


It is general wisdom that a key should only be used for a single purpose. Using the same key for multiple purposes is like swimming in shark-infested waters with a leg wound. It's not guaranteed to kill you, but that doesn't make it a good idea.

One of the things that can go wrong is if the same construction has a different meaning in the two systems. For example, in system A, signing the message $M$ means “I give Bob 42 units”, and in system B signing the same message $M$ means “I give Charlie 24 units”. Many cryptosystems use uniquifiers to avoid this kind of problem, for example by only ever accepting messages that start with "in system A:". If both systems have uniquifiers that ensure that no message can be valid for both systems, then using the same key is ok with respect to this pitfall. I have no idea whether this is the case for Matrix and Solana.

A more subtle indirect variant of this pitfall is consequences of implementation flaws. For example, maybe the software for system A has a side channel vulnerability, but it's only a partial leak that doesn't provide enough information to construct a useful attack. Meanwhile system B runs on a platform that's weak to glitch attacks, but there's no practical way to trigger a glitch that's useful for system B because it's been constructed to defend against those glitches. However, the partial information from system A is enough to construct a useful glitch that breaks system B. This is basically a more subtle, but more realistic of “you can extract the first half of the key from system A and the second half of the key from system B”. A lot of real-world attacks against systems that people have seriously tried to secure are like that: exploiting a combination of flaws, each of which does not result in a meaningful attack on its own. Sharing secret material between systems increases the risk.

Another reason to avoid using the same key for different purposes is that if the key is compromised, this increases the impact. Somebody manages to distribute a fake Matrix client that extracts private keys, and oops, now the attacker also has your Solana key.

Besides the benefits you list are actually quite dubious.

reduction in key management

In practice, probably not. You'll have to feed the key to both the Solana software and the Matrix software, meaning more exposure for the key than if each key is only known to one of the systems. Most keys are kept online and usable, not in secure vaults where they are only accessed once a year with ample prior notice.

being able to re-use identities tied to existing public keys.

Tying identities to public keys is in itself a bad idea. It makes it very painful to revoke the key: you have to change identities! There's a reason PKI exists. Tying identities to public keys also negates privacy.

  • $\begingroup$ Good points re: attacks using leaks from both systems, and also the unexpected behaviour of a leak in one meaning a user is vulnerable in the other. PKI's raison d'etre is tying identities to public keys, and obviously not all identities have to be real-world, but that's a conversation for another time. $\endgroup$ Commented Jul 6, 2023 at 21:17
  • 1
    $\begingroup$ CAs today issue S/MIME, TLS/HTTPS and Microsoft code signing X.509 certs using the same CA and certificate chains. The OS maintains a single trusted CA list. The cert being used right here covers multiple identities (*.stackexchange.com, *.superuser.com, etc). So it seems that benefits of key management and identity management are exploited, for at least the protocols mentioned. $\endgroup$
    – user71659
    Commented Jul 7, 2023 at 19:15
  • $\begingroup$ +1. For your "different meaning" example: this would actually be a problem even if the message means "I give Bob 42 units" in both systems, since you want to be able to pay Bob 42 units in one system without also paying him 42 units in the other! $\endgroup$
    – ruakh
    Commented Jul 7, 2023 at 23:02

No, it is not reasonable to re-use a keypair across multiple systems which specs have been independently derived, even if they use the same signature system and parameters.

Problem is that the same message could make sense for both systems, and then the signature of that message would be usable under both systems. So a user making a purchase under one system could find they also signed for a purchase (perhaps much different) under the other system.

  • 1
    $\begingroup$ Ah, if the exact same transaction format was used in both systems. I'm not sure if it's sufficient to abandon the concept, but it's certainly a valid concern, have an upvote. $\endgroup$ Commented Jul 6, 2023 at 21:12

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.